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DEVELOPING  A  GENERAL  CONTINGENCY  PLANNER,  PHASE  II 

1.  INTRODUCTION 

A  good  deal  of  the  research  conducted  in  Artificial  Intelligence  (Al)  over  the  last 
thirty  years  has  focused  on  the  development  of  systems  ror  generating  plans  of  action 
for  agents  faced  with  numerous,  complex,  and  conflicting  goals.  Because  planning  is 
such  a  vital  part  of  the  military  function,  the  promise  of  these  systems  is  of  great  interest 
to  the  military  community.  Foremost  among  the  contributions  that  could  be  made  by 
reliable  Al-based  planning  systems  would  be  1)  the  ability  to  monitor  complex 
situations  where  large  quantities  of  data  need  to  be  assimilated  quickly,  and  2)  the 
ability  to  project  outcomes  of  possible  courses  of  maneuver  in  dynamically  evolving 
battlefield  environments. 

This  report  discusses  the  problem  of  extending  the  action-planning  techniques 
developed  in  Artificial  Intelligence  research  to  problems  involving  the  need  to  plan 
against  an  intelligent  adversary.  The  focus  of  the  report  is  work  completed  by  PAR 
Government  System  Corporation  (PGSC)  during  the  final  phase  of  a  three-year  basic 
research  effort.  The  remainder  of  this  section  of  the  report  presents  a  general 
discussion  of  the  nature  of  adversity  and  the  special  considerations  which  must  be 
taken  into  account  by  any  automated  planning  systom  which  is  to  operate  in  a  domain 
characterized  by  adversity.  Section  2  explains  the  basic  representational  structure  at 
the  heart  of  the  planner  developed  on  this  effort:  Contingency  Goal  Trees.  Section  3 
explains  the  generation  of  these  trees.  Section  4  focuses  on  the  representation  of 
planning  knowledge  in  the  form  of  goal  elements  and  how  these  are  structured 
syntactically.  Sections  5  and  6  provide  two  illustrative  examples  of  how  the  planning 
system  functions.  Section  5  is  an  example  of  the  planner's  operation  in  the  two-player 
board  game  of  Othello,  which  was  the  domain  of  interest  during  the  first  phase  of  work. 
Section  6  presents  a  planning  scenario  which  is  orienteo  toward  army  maneuver 
planning.  This  was  the  domain  of  interest  during  the  second  phase.  A  summary  of  the 
entire  effort,  along  with  assessments  of  the  degree  of  success  of  the  work,  is  given  in 
Section  7,  and  a  complete  listing  of  the  source  code  for  the  planning  system  is 
provided  in  the  Appendix. 

The  ability  to  act  for  an  end  has  long  been  used  to  characterize  the  special 
nature  of  human  beings.  Aristotle  was  among  the  first  to  recognize  this  fact,  which  has 
served  as  a  definition  of  intelligent  activity  ever  since.  If  computerized  agents  are  to  be 
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successful  and  truly  useful  in  a  complex  world,  ways  must  be  found  that  will  allow  them 
to  copy,  or  closely  approximate,  the  planning  skills  of  men. 

The  attainment  of  a  goal  does  not  happen  automatically.  It  is  not  enough  for  an 
agent  to  simply  have  a  goal  in  mind:  an  effort  is  required  to  accomplish  the  goal.  To 
understand  this  we  need  only  attend  to  the  fact  that  the  world  or  environment  that 
confronts  any  agent,  either  human  or  not,  is  one  that  is  full  of  obdurate  and  self- 
insistent  things  that  oppose  the  agent.  Among  these  are  other  agents  with  their  own 
goals,  objects  like  rocks  and  trees  that  can  get  in  the  way,  and  roads  with  forks  in  them. 
Each  of  these  can  oppose  the  agent  in  the  attainment  of  its  ends.  The  collection  of 
stubborn  realities  which  can  impede  an  agent  can  be  seen  as  forming  a  general 
condition  of  adversity  which  permeates  every  environment  or  domain  where  an  agent 
would  attain  a  goal.  Adversity  arises  in  all  domains  no  matter  how  simple  or  complex, 
and  it  is  this  condition  of  adversity  that  separates  every  agent  from  its  goal.  The  central 
issue  in  automated  planning  is  then  the  problem  of  dealing  with  adversity  --  adversity 
created  by  the  stubbornness  of  whatever  is  the  non-agent. 

In  a  sense,  adversity  has  always  been  recognized  as  the  impediment  to  action 
planning  by  researchers  in  this  field,  in  every  case,  however,  the  general  problem  of 
adversity  has  remained  hidden  from  view  and  unattended  to  as  a  result  of  the  attention 
given  to  the  special  form  of  adversity  in  a  given  domain.  Examples  of  this  kind  of 
oversight  can  be  seen  in  the  kinds  of  problems  usually  dealt  with  in  automatic 
problem-solving  research  ar.d  the  way  in  which  these  problems  are  approached. 

Usual'/ ,  a  problem-solving  program  will  be  centered  around  the  solution  of  a 
single  problem  (e.g.,  the  familiar  blocks  world)  or  a  family  of  related  problems.  In  most 
of  these  treatments,  the  result  has  been,  at  best,  a  problem  solver  which  is  successful 
only  in  the  realm  of  the  class  of  problems  under  consideration.  This  limitedness  arises 
from  taking  a  particular  problem  or  proDlem  set  as  representative  of  problem  solving  in 
general  and  then  building  a  solution  for  that  particular  instance.  Created  are  a 
multitude  of  problems  solvers,  each  of  which  may  be  fairly  successful  in  its  own 
restricted  domain,  but  is  of  little  value  in  a  general  sense.  In  each  of  these 
approaches,  there  are  special  devices  for  constraining  search  among  alternatives, 
resolving  conflicts  among  alternatives,  and  resolving  conflicts  among  competing 
subgoals.  What  has  been  missed  by  a  good  deal  of  the  previous  research  in 
automatic  problem  solving  is  that  all  action  planning  shares  a  common  feature  --  it  is 
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oniy  necessary  because  of  the  general  condition  cf  adversity  which  confronts  any 
agent  acting  for  an  end.  If  the  other  features  of  the  world  (the  non-agent)  were 
incapable  of  resisting  and  opposing  the  agent,  there  would  be  no  need  for  planning, 
subgoals,  or  any  other  effort:  all  ends  would  be  achieved  instantaneously  by  the 
power  of  the  agent's  will.  However,  because  the  real  world  has  an  integrity  and  status 
apart  from  the  agent,  the  agent  is  rigorously  opposed,  and  the  collection  of  oppositions 
with  which  the  agent  is  confronted  can  be  seen  as  a  condition  of  adversity.  Once  this 
commonality  has  been  discovered,  it  becomes  possible  to  propose  a  model  or 
paradigm  for  problem  solving  in  general  and  thereby  arrive  at  a  truly  domain- 
independent  problem  solver. 

A  simple  example  will  serve  to  demonstrate  that  adversity  is  a  common 
condition  for  all  problem  solving  activity.  Consider  the  planning  problem  depicted  in 
Figure  1-1.  Here,  the  goal  is  to  capture  the  city  with  the  given  units  which  are  initially 
on  the  wrong  side  of  the  river.  The  objective  can  be  expressed  in  the  form  of  a  single¬ 
node  plan  (utilizing  Sacerdoti’s  procedural  network  formalism)  as  shown  in  Figure  1-2. 


This  single  node  can  be  expanded  into  a  more  detailed  plan  by  breaking  the 
conjunction  into  its  components.  The  resulting  decomposition  is  shown  in  Pigure  1-3. 
The  three  subproblems  are  shown  in  parallel  in  order  to  indicate  that  there  is  no  a 
priori  commitment  to  a  temporal  sequence.  Obviously,  however,  for  the  goal  to  be 
achieved,  the  subproblems  must  be  solved  in  a  particular  order.  In  this  case,  the  city 
cannot  be  attacked  until  the  units  are  ae  oss  the  river,  and  the  units  cannot  get  across 
the  river  until  the  bridge  has  been  built.  Such  an  interaction  between  subproblems 
has  been  termed  a  “conflict"  by  Sacerdoti  Conflicts  are  resolved  by  the  application  of 
a  device  known  as  a  “critic,”  wnich  looks  for  special  kinds  of  interaction  in  a  developing 
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Figure  1-3 


plan  and  adjusts  the  plan  accordingly.  Critics,  because  they  are  intended  to  be 
applicable  to  multiple  planning  situations,  are  necessarily  ore-defined. 

The  conflicts  in  the  simple  plan  developed  so  far  would  be  resolved  by  a  critic 
(or  critics)  that  knew  that  a  precondition  for  being  near  something  on  the  other  side  of  a 
river  would  be  the  use/construction  of  a  bridge  to  get  across.  After  resolution  of  the 
conflicts,  the  CAPTURE_CITY  plan  would  look  as  shown  in  Figure  1-4. 


A  close  look  at  the  initial  problem  (Figure  1-1)  and  the  current  plan  (Figure  1-4) 
shows  that  there  is  still  some  ambiguity  in  that  there  are  three  distinct  units  to  be 
moved  across  the  river.  Therefore,  the  pian  can  be  further  decomposed  into  a  new  set 
of  subproblems.  Each  of  these  new  subproblems  would  represent  a  step  for  moving 
each  of  the  three  units  across  the  river.  The  new,  more-complete  plan  is  shown  in 
Figure  1-5. 
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Figure  1-5 


Once  again,  the  subproblems  are  shown  in  parallel,  and,  as  long  as  the  three 
units  represent  the  same  or  similar  resources,  this  plan  is  fine.  In  a  real  military¬ 
planning  situation,  however,  unit  A  may  be  artillery,  unit  B  infantry,  and  unit  C  armor. 
In  this  case,  the  order  of  sending  the  units  across  may  make  a  great  deal  of  difference 
to  the  success  of  the  operation.  If  the  infantry  crosses  first,  it  will  be  subjected  to  the  full 
fury  of  the  enemy's  resistance,  while  the  armor  (unit  C)  will  be  following  uselessly 
behind.  There  is,  therefore,  a  new  conflict  among  subproblems  in  the  plan,  and  this 
conflict  will  have  to  be  resolved  by  yet  another  critic.  One  possible  criticism  might*be 
represented  by  a  rule  which  holds  that  armor  always  precedes  infantry  and  that  the 
artillery  follows  the  infantry.  Another  possibility  might  be  a  critic  which  knows  that, 
within  a  certain  range,  the  artillery  could  be  left  on  the  far  side  of  the  river  and  fire  on 
the  city  from  there.  A  simple  resolution  to  the  conflict  is  shown  by  the  new  plan  in 
Figure  1-6. 

Conflict  resolution  forms  another  primary  problem  in  the  development  of 
automatic-planning  systems  from  the  standpoint  of  Command  and  Control  problems. 
Notice  that  both  resolutions  in  the  river-crossing  example  were  achieved  by  the 
addition  of  new  knowledge  into  the  planning  process:  specifically,  knowledge  about 
the  sequencing  of  actions  with  respect  to  time  for  attacking  the  city  and  how  to  use 
different  kinds  of  resources  in  that  attack.  The  way  this  knowledge  is  usually  handled 
is  in  the  form  of  special  general-purpose  rules.  These  rules,  by  virtue  of  the  fact  that 
they  must  be  pre-defined,  can  be  described  as  static,  that  is,  they  cannot  take  any 
account  of  factors  or  conditions  external  to  the  explicit  ones  embodied  In  their  own 
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logic.  The  rule,  or  critic,  looks  for  particular  interdependencies  and  resolves  these 
conflicts  in  some  prescribed  manner.  As  such,  it  has  no  capability  to  reason  about  the 
particular  situation  at  hand  and  what  the  implications  of  the  application  of  the  general 
criticism  are  for  that  special  circumstance. 

The  following  three  sections  discuss  in  depth  PGSC’s  approach  to  meeting  the 
challenges  presented  by  planning  in  adversarial  domains.  First.  Section  2  discusses 
a  framework,  known  as  Contingency  Trees,  for  representing  adversarial  plans  of 
action.  Section  3  discusses  in  detail  the  planning  mechanism  which  is  utilized  to 
generate  these  trees,  and  Section  4  presents  the  knowledge-representational  scheme 
for  representing  the  actual  goal  knowledge. 
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2.  THE  STRUCTURE  OF  CONTINGENCY  GOAL  TREES 


The  planning  system  which  PAR  Government  Systems  Corporation  (PGSC) 
developed  represents  plans  as  contingency  goal  trees  (CGTs).  Contingency  goal 
trees  are  a  hybrid  plan-representation  structure  embodying  aspects  of  traditional 
hierarchical  plan  representations  and  of  move  trees  from  computer  game  playing. 
Figure  2-1  is  a  sample  CGT  with  19  nodes.  The  19  nodes  of  the  CGT  are  organized 
into  six  levels  of  abstraction.  Abstraction  refers  to  the  need  in  planning  systems  to 
represent  problems  in  different  degrees  of  resolution  or  generality.  What  is  intended 
by  the  concept  of  abstraction  can  be  seen  in  terms  of  the  frequently  used  "pasta- 
.■naking’"example.  One  might  want  to  create  a  plan  for  making  pasta,  which  can  be 
represented  as  the  goal:  (MAKE_PASTA).  This  goal  can  be  thought  of  as  having  two 
SUb-goals:  (BOIL  WATER)  and  (PLACE_PASTAJN_WATER).  These  two  subgoals 
are  said  to  be  at  a  lower  level  of  abstraction  because,  while  they  represent  an 
equivalent  notion  to  the  initial  goal,  the  problem  is  nonetheless  represented  in  a  more- 
detailed,  specific,  and  therefore  less-abstract  way.  Similarly,  the  MAKE_PASTA  goal 
may  be  less  abstract  than  an  even-higher  level-goal:  HAVE  DINNER.  for  example. 

Abstraction  is  a  key  idea  in  planning  because  it  allows  for  multiple  views  of  the 
same  problem,  each  of  which  is  at  a  different  level  of  detail.  Details  are  usually 
numerous,  hard  to  keep  track  of.  and  not  always  important.  Therefore,  the  ability  to 
represent  plans  at  more  than  one  level  of  detail  or  abstraction  allows  for  the 
convenient  collection  of  specific  parts  of  planning  knowledge  under  broader  concepts 
which  may  be  more  easily  manipulated  and  traced. 

The  lowest  level  of  abstraction  in  any  computer  plan  represents  what  may  be 
called  ‘acts'  in  the  world  of  the  planning  system.  The  purpose  of  an  automated 
planner  is  to  develop  plans  for  achieving  some  goat.  Regardless  of  how  many  levels 
of  abstraction  the  planning  problem  may  be  decomposed  into,  the  plan  must  terminate 
in  nodes  which  are  not  subgcais  requiring  fu'tner  development,  but  rather  actions  for 
implementing  the  plan  in  the  pre-oefined  world  of  the  planning  system.  Thus,  a  robot 
planner  may  have  numerous  goai  nodes  ranging  across  multiple  levels  of  problem 
abstraction  (e.g.,  (OPEN_DOOR  DOOR1)).  In  the  end.  however,  the  plan  must  be 
made  applicable  tc  the  world  in  which  the  planner  is  to  operate.  Applicability  is 
achieved  through  the  generation  of  bottom-level  nodes  which  correspond  to  acts  in  the 
planner's  world. 


A  planner  for  developing  a  sequence  or  piling  or  unpiling  a  set  of  blocks  would 
have  acts  corresponding  to  the  movement  of  particular  blocks,  while  a  planner 
designed  to  maneuver  a  fighter  jet  in  a  dog  fight  would  have  acts  corresponding  to 
ai'eron  adjustment  and  so  on.  Above  each  act  is  a  network  of  goals  which  are  the 
ancestors  of  the  act  and,  in  a  sense,  explain  why  the  act  is  being  recommended. 
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Sample  CGT  with  19  Nodes 
Figure  2-1 


To  illustrate,  consider  the  representation  depicted  in  Figure  2-2.  This  figure 
shows  a  hierarchically  decomposed  solution  to  the  high-level  problem  “Engage 
Target  X  at  Time  Y.”  In  this  extremely  simplified  example,  there  are  three  levels  of 
abstraction.  Th*  first,  or  top  level,  states  the  initial  problem.  This  is,  in  turn,  resolved 
into  a  three-step  plan  at  a  lower  level  of  abstraction.  At  this  more  concrete  level,  an 
explicit  strategy  (“SHOOT_LOOK_SHOOT")  for  achieving  the  higher-level  goal  is 
instantiated.  Finally,  at  the  lowest  level  of  abstraction  are  the  acts  or  discrete  steps 
required  to  perform  the  three  steps  shown  in  Level  2. 


Example  of  Hierarchical  Decomposition 
Figure  2-2 
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It  is  important  to  recognize  that  the  question  “to  what  level  of  decomposition  or 
abstraction  a  problem  should  be  reduced”  will  vary  with  the  aims  of  the  particular 
planning  system.  That  is,  there  is  no  pre-defined  lowest  (or  highest)  target  level. 
Instead,  these  will  be  defined  within  the  context  of  the  given  system.  It  would  have 
been  possible,  for  example,  to  build  a  planner  which  immediately  instantiates  the  goal 
“Engage  Target  X  at  Time  Y”  into  some  solution.  In  that  case,  the  “Engage  Target” 
goal  would  also  h  'onsidered  an  act.  As  one  pushes  the  level  of  acts  further  and 
further  away  from  the  level  of  the  initial  problem  state,  thereby  creating  more  levels  of 
abstraction,  the  planner  is  made  more  flexible  and  more  able  to  apply  to  general 
situations.  Thus,  the  initial  representation  (Figure  2-2)  has  four  acts,  each  of  which  is 
related  to  a  procedure  for  instantiating  that  act.  This  is  in  contrast  to  the  situation  that 
would  hold  if  there  were  only  a  single  procedure  for  achieving  “Engage  Target  X  at 
Time  Y.”  The  former  is  more  flexible,  because  the  four  acts  with  their  associated  four 
procedures  can  be  combined  in  numerous  ways  to  solve  the  problem  differently  or 
even  to  solve  completely  different  problems. 

To  address  planning  problems  that  involve  an  intelligent  adversary,  this 
research  effort  has  taken  the  approach  of  generalb  -  the  goal-tree/procedural- 
network  formalisms  to  represent  plans  in  a  manner  tha  .mits  incorporating  the  type 
of  planning  that  is  done  in  knowledge-based  game-pl?  research.  To  this  basic 
framework  has  been  added  explicit  consideration  of  adve:  i\  countergoals. 

The  basic  premise  of  the  research  effort  was  that  most  of  the  previous  work  in  Al 
planning,  such  as  that  derived  from  robot  problem  solving,  cannot  be  readily  applied  to 
military-planning  problems.  Specifically,  these  planners  lack  a  satisfactory  capability 
to  explicitly  incorporate  an  adversary's  goals  and  actions  into  the  planning  process. 
Consequently,  they  cannot  effectively  plan  against  an  adversary  that  is  simultaneously 
planning  against  them.  As  an  example,  consider  the  case  of  planning  under 
conditions  of  uncertainty.  One  accepted  technique  is  to  include  information-seeking 
goals  in  the  plan  whenever  information  necessary  tb  complete  a  plan  is  not  initially 
available  to  the  planner  (e.g.,  FIND_LOCATION  (X),  if  the  location  of  X  is  not  known). 
When  an  adversary  is  present,  however,  that  adversary  is  likely  to  have  a  countergoal 
of  preventing  the  collection  of  the  required  information.  Consequently,  this  adversary 
will  use  various  tactics,  perhaps  including  deception,  to  prevent  information  collection. 
Unless  the  adversary’s  countergoals  and  actions  are  explicitly  taken  into  account  and 
planned  against,  the  original  information  goal  is  not  likely  to  be  achieved. 
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The  planner  which  this  research  developed,  ARES  (Adversarial  REasoning 
System),  represents  plans  in  a  structure  called  a  Contingency  Goal  Tree  (CGT). 
Figure  2-1  is  a  sample  CGT  showing  a  plan  for  some  hypothetical  battle  situation.  At 
each  node  in  a  CGT  is  a  Goal  Pair  (GP)  which  includes  a  proposed  friendly  goal  and  a 
possible  countergoal  for  the  adversary.  Sub-nodes  of  GPs  are  Sub-Goal  Pairs 
(SGPs).  Reading  the  left-most  branch  of  the  example  CGT,  a  sub-goal  of  CAPTURE 
(A)  is  SURROUND  (A),  while  the  corresponding  sub-goal  of  DEFEND  (A)  is  RETREAT 
(A).  Consequently,  the  GP  CAPTURE  (A)  :  DEFEND  (A)  has  as  its  first  SGP 
SURROUND  (A)  :  RETREAT  (A). 

Simultaneous  multiple  tasks  are  treated  as  conjunctive  (AND)  or  disjunctive 
(OR)  goals.  Thus,  (AND  ENC(PI)  ENC(P2))  is  a  single  goal  of  enclosing  both  escape 
path  1  and  escape  path  2,  while  (OR  ESC(PI)  ESC(P2))  is  a  goal  of  escaping  through 
either  path  1  or  path  2.  Other  “generic”  goals,  such  as  AND_IN_SEQUENCE,  are 
possible. 

In  many  instances,  GPs  will  include  a  goal  or  countergoal  of  NIL.  This  occurs 
when  there  is  no  projected  opposing  goal,  such  as  when  ARES  is  exploring  an  option 
where  one  side  pursues  an  independent  course  of  action  while  ignoring  the 
adversary’s  goals.  It  also  happens  to  occur  in  example  CGT  because  this  example 
depicts  a  linear  sequence  of  moves  and  countermoves,  as  would  be  found  in 
alternating-move  games  such  as  Chess. 

When  a  CGT  contains  a  NIL  element  in  every  GP,  it  is  isomorphic  to  a  standard 
goal  tree.  Also,  CGTs  can  have  parallel  branches  and,  if  desired,  pre-conditions  and 
post-conditions  attached  to  nodes.  Consequently,  CGTs  represent  a  straightforward 
extension  of  the  goal-tree/procedural-network  representation. 
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3.  GOAL-COUNTERGOAL  PAIRING:  CGT  GENERATION 


Section  2  described  the  means  of  representing  plans  in  the  planner  PAR 
Government  Systems  Corporation  (PGSC)  developed.  This  section  deals  with  the 
process  used  to  generate  contingency  goal  trees. 

Given  that  plans  of  action  are  to  be  represented  in  the  form  of  hierarchically 
decomposed  networks  where  higher-level  abstract  goals  are  resolved  into  more 
detailed,  less-abstract  component  parts,  the  next  question  pertains  to  what  mechanism 
is  to  be  used  to  accomplish  the  actual  reduction  of  one  level  of  goal  into  its  more 
detailed  components.  Given  some  initial  problem,  an  automated  planner  requires 
some  means  of  generating  the  network  of  goals  and  subgoals  that  represent  the 
solution. 

The  plan-network-generation  problem  is  in  a  class  known  as  state-graph  search 
problems,  where,  given  an  initial  state,  an  exploration  of  possible  sequences  of  future 
states  is  performed  in  the  hope  of  isolating  a  path  that  will  lead  to  a  goal  state.  Figure 
3-1  shows  a  state  graph  for  some  imaginary  problem.  In  this  example,  Node  A 
represents  the  initial  state  and  Node  H  the  desired  goal  state.  The  problem  is  to  find  a 
path  that  leads  from  A  to  H. 

Another  related  form  of  this  representation  is  the  commonly  known  move  tree 
from  computer  game  playing.  In  a  move  tree,  a  particular  node  represents  some  legal 
arrangement  of  playing  pieces  on  the  board.  The  “children”  of  that  given  node  will  be 
the  complete  set  of  possible  legal  moves  for  the  side  on  the  movj.  Each  of  these 
nodes  becomes,  in  turn,  the  starting  point  for  proposing  a  set  of  subsequent  moves  for 
the  opposite  side.  Figure  3-2  shows  a  sample  move  tree  for  a  very  simple  Chess 
game  where  there  are  nine  squares,  a  White  Bishop,  and  a  Black  Rook.  Reading  this 
tree  from  the  top  down,  first  ail  the  possible  moves  are  found  for  the  Black  Rook.  At  the 
next  level,  each  of  the  possible  White  responses  to  the  Biack  moves  is  postulated. 

In  procedural  networks,  state  graphs,  and  move  trees,  the  basic  problem  is  how 
to  fi.id  a  path  that  will  lead  to  the  desired  state.  Numerous  alternatives  are  possible. 
The  first  and  most  obvious  means  is  to  exhaustively  enumerate  all  the  possibilities. 
Inevitably  this  results  in  a  great  deal  of  wasted  effort  because  usually  only  a  relatively 
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There  are  numerous  possible  ways  to  cut  down  the  amount  of  computational 
effort  required  to  navigate  through  the  network.  Breadth-first  Search  examines  all  the 
elements  at  each  level  (horizontally)  before  proceeding  depth  wise  to  the  next  level. 
Depth-first  Search  expands  the  state  graph  vertically  until  a  path  either  leads  to  a 
success  or  a  dead  end.  If  a  dead  end  is  reached,  the  search  backs  up  to  the 
immediate  prior  node  and  seeks  an  alternative  at  that  level,  and  so  on. 

In  a  recent  article,  deKleer  (1985)  identifies  three  principal  ways  of  exploring  a 
search  space.  The  first,  and  most  common,  brute-force  enumeration  of  all  possibilities, 
was  described  above.  An  alternative  approach  is  chronological  backtracking  (a 
variant  of  depth-first  search).  However,  the  discovery  of  a  failure  in  the  developing 
plan  may  result  in  a  large  amount  of  wasted  work  because  the  real  reason  for  the 
contradiction  in  the  plan  may  be  some  choice  further  back  in  the  plan,  not  necessarily 
the  immediately  prior  one.  As  deKleer  writes:  "When  a  contradiction  is  discovered  the 
search  should  backtrack  to  a  choice  which  contributed  to  the  contradiction,  not  to  the 
most  recent  choice."  A  second  alternative  to  brute-force  enumeration  is  known  as 
dependency-directed  backtracking  (another  variant  of  depth-first  search).  In 
dependency-directed  backtracking,  records  are  kept  about  the  dependency 
relationship  that  each  choice  in  a  plan  has  with  regard  to  prior  choices.  When  a  failure 
in  the  plan  occurs,  dependency  records  are  examined  to  determine  which  prior 
choices  (not  necessarily  the  last  one)  set  up  this  situation. 

In  actuality,  most  planners  employ  a  hybrid  approach  for  developing  plans  of 
action:  neither  pure  breadth  first  nor  pure  depth  first.  A  popular  hybrid  is  known  as 
best-first,  where  the  most  promising  alternative  at  each  level  is  explored  first. 

Figure  3-3  is  an  example  of  a  best-first  expansion.  At  each  level,  some 
procedure  is  used  to  select  the  “best”  node  for  expansion.  Once  a  node  is  selected 
within  a  level,  the  planner  proceeds  to  evaluate  the  children  of  that  node  seeking  to 
identify  the  best  possible  one  to  expand,  in  turn.  This  continues  in  the  same  manner 
as  a  depth-first  search,  except  that  some  discrimination  is  performed  at  each  level 
among  the  possible  nodes  to  expand.  The  expansion  results  in  the  location  of  either  a 
successful  path  or  a  dead  end.  If  the  path  has  led  to  a  dead  end  (a  failure), 
backtracking  is  undertaken  to  some  prior  node,  where  the  expansion  begins  anew. 
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Best-Fit  Example  With  Sample  Scores 
Figure  3-3 

The  approach  taken  to  planning  in  ARES  is  a  hybrid  of  these  other  techniques. 
By  reading  the  terminal  nodes  of  a  CGT  from  left  to  rig!  ,  a  specific  sequence  of 
actions  is  defined.  Consequently,  each  CGT  specifies  a  contingency  plan  if  the 
adversary  pursues  the  goals  indicated  in  the  tree.  In  an  adversarial  world,  “good 
planning”  means  generating  contingency  plans  for  each  reasonable  course  of  action 
that  either  the  adversary  or  the  agent  may  pursue.  To  this  end,  ARES  attempts  to 
generate  a  set  of  CGTs  that  provides  contingency  plans  for  the  full  scope  of 
reasonable  options  available  to  th  j  agent  and  the  adversary. 

For  a  given  level  of  abstraction,  ARES  proceeds  through  CGT 
generation/expansion  in  a  depth-first  manner.  Beginning  with  the  most  recent  GP 
added  to  the  CGT,  ARES  recursively  adds  SGPs  until  a  terminal  GP  is  reached.  A 
terminal  GP  includes  a  procedure  for  making  an  action  in  the  world,  which  means  that 
it  is  the  lowest  level  in  the  expansion.  Processing  a  GP  involves  accessing  a 
knowledge  base  of  goal  definitions  in  order  to  determine  possible  reasonable  options 
to  instantiate  lor  either  the  agent  or  the  adversary.  In  alternating-move  games,  these 
accesses  are  for  the  goal  for  the  side  that  is  currently  on  the  move.  In  more 
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complicated  domains,  like  maneuver  planning,  where  actions  can  occur 
simultaneously,  both  parts  of  the  GP  are  processed  at  the  same  time. 

In  the  example  CGT,  the  solid  line  identifies  those  SGPs  that  were  generated  by 
processing  the  parent  goal  of  side  A,  on  the  left,  while  dotted  lines  indicate  SGPs  that 
are  descended  from  the  parent  goal  of  side  B,  on  the  right. 

The  general  procedure  employed  by  ARES  in  the  generation  of  plans  may  be 
characterized  as  an  iterative  process  of  proposing  possible  courses  of  action  and, 
based  on  the  outcome  of  those  actions,  proposing  better  action  options.  ARES,  in 
effect,  plays  out  a  series  of  hypothetical  games  in  order  to  “learn”  about  the  way 
objects  in  the  domain  interact.  The  knowledge  that  is  gained  is  further  used  in  the 
construction  of  the  network  of  goals  and  countergoals. 

Table  3-1  presents  a  high-level,  English-language  description  of  the  actual 
procedure  used  by  ARES  to  generate  CGTs.  The  procedure  “RESOLVE”  is  recursively 
called  until  goal  decomposition  ends  with  either  a  failure  or  an  act  in  the  world  state. 


TABLE  3-1 


Procedure  RESOLVE 

1 .0  Given  an  initial  input  goal  pair,  designated  gpair,  determine  whether  it  will  result  in 
success  lor  either  agent  or  counter  agent.  Contingency  Goal  Trees  created  in  this 
process,  taken  together,  form  a  plan. 

2.0  IF  a  word  update  action  can  be  performed,  THEN  perform  it  and  RETURN  T. 

3.0  Generate  a  new  sub-goal  pair  ( sub-gpaii )  for  gpair  and  add  to  sublist 

4.0  CASE: 

sub-gpair  :  go  to  7.0 

(RESOLVE  (sub-gpair  side))* NIL:  go  to  3.0 
ENDfcase}, 

5.0  Replace  most  recent  sub-gpair. 

6.0  IF[AND(  sub-gpairT)  (RESOLVE(sub-gpair  side))],  THEN  go  to  3.0 

7.0  CASE: 

sublist  >  0  AND  (side  effects)  :  go  to  5.0 

sublist  >  1  :  Remove  one  sub  and  go  to  5.0 

sublist  =  1  :  RETURN  T 

sublist  =0  :  RETURN  NIL 

END  (case). 
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4.  KNOWLEDGE  REPRESENTATION  IN  PLANNING 


Computer  game  playing  and  robot  problem  solving  are  generally  considered  to 
represent  distinct  classes  of  planning  problems.  The  normal  model  for  examining  two- 
player,  perfect-information  game  problems  starts  with  a  game  tree  which  maps  the 
various  possible  situational  evolutions  that  can  occur,  given  different  action  options  for 
the  two  sides.  As  pointed  out  in  Section  2,  for  even  the  simplest  games,  such  trees 
can  develop  to  unmanageable  size  after  only  a  few  levels,  introducing  the  need  for 
clever  techniques  for  isolating  the  best  move  based  on  only  a  partial  look-ahead. 

Several  possible  methods,  including  minimax  and  alpha-beta  (see  Nilsson, 
1980  for  a  review)  exist  for  constraining  the  search  problem.  Other  researchers  have 
coupled  these  techniques  with  the  use  of  heuristics  and  the  incorporation  of  domain- 
specific  techniques  to  limit  searching  in  a  given  game  problem  (Ballard,  1982). 

Two  issues  appear  to  be  most  important  for  the  creation  of  a  successful  planner 
in  any  domain:  1)  a  knowledge-representation  strategy  and  2)  a  mechanism  for 
applying  knowledge  in  an  attempt  to  constrain  the  search  space.  This  report  section 
details  the  major  results  of  PGSC’s  investigations  with  respect  to  this  important  aspect 
of  automated  planning. 

PGSC  contends  that  the  classes  of  problems  described  generally  as  computer 
game  playing  and  automatic  problem  solving  do  not  represent  unrelated  domains 
within  Al  but  are  rather  special  cases  of  a  broader  problem  set  which  can  be  best 
categorized  as  dynamic  plan  generation. 

A  major  impetus  behind  PGSC  research  in  this  area  has  been  the  state  of  two- 
player,  perfect-information  games  over  the  last  20  years.  This  sad  situation  has  been 
summarized  by  Berliner  (1973)  with  his  criticism  that  one  of  the  most  serious 
deficiencies  in  game-playing  programs,  like  those  being  developed  for  Chess,  was  the 
absence  of  long-range  or  global  plans  for  winning  the  game.  Wilkins  (1979),  with  his 
PARADISE  system,  provided  further  guidance  by  restating  the  game-playing  problem 
in  terms  of  planning  issues.  The  essence  of  Wilkins’  approach  is  to  develop  move 
sequences  based  upon  the  goal-directed  development  of  a  plan,  instead  of  picking  the 
“best”  move  from  a  tree  expanded  to  some  arbitrary  depth  according  to  some  arbitrary 
method.  The  result  is  that  the  emphasis  in  developing  successful  game-playing 
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programs  is  shifted  from  questions  of  computational  complexity  to  the  construction  of 
effective  goal-based  knowledge-representation  schemes. 

The  use  of  long-range  planning  and  goal-based  knowledge  has  been 
successfully  employed  in  a  number  of  planning  mechanisms  (see  Berliner,  1975; 
Reitman  and  Cox,  1979;  and  Wilkins,  1979).  In  all  of  these  systems,  knowledge  is 
employed  in  order  to  constrain  a  space  of  available  options.  Once  candidate 
strategies  are  identified,  thereby  eliminating  many  branches  of  the  move  tree,  action 
alternatives  can  be  investigated  to  considerable  depth  without  suffering  from  the 
effects  of  a  combinatorial  explosion. 

Controlling  the  generation  and/or  search  of  a  set  of  action  alternatives 
represents  one  of  the  primary  problems  facing  development  of  successful  computer 
planners  in  all  domains,  not  simply  game  playing.  The  crux  of  the  problem,  as  it  is 
commonly  presented,  is  that  finding  solutions  to  planning  problems  requires  either  an 
epistemologically  intensive,  or  a  time-intensive  approach.  The  former  requires  that 
sufficient  knowledge  (e.g.,  about  strategies,  good  skeletal  planning  sequences,  etc.) 
be  included  in  the  planner  to  guide  the  decision  making  required  to  select  among 
competing  courses  of  action.  The  latter  approach,  on  the  other  hand,  foregoes  this 
kind  of  goal  directedness,  developing  all  branches  to  a  certain  level  and  then  picking 
the  best  move  by  applying  some  criteria  to  the  family  of  alternatives. 

Several  researchers  have  recognized  this  dilemma  and  suggested  that  these 
two-solution  strategies  are  arrayed  along  a  kind  of  continuum  and  that  other  methods 
that  attempt  to  combine  the  two  lie  between  the  two  extremes.  McCarthy  and  Hayes 
(1969)  and  Berliner  (1973)  are  examples. 

As  Berliner  pointed  out,  approaches  to  planning  action  sequences  which 
depend  either  entirely  on  knowledge  or  search  are  essentially  uninteresting  from  the 
standpoint  of  Artificial  Intelligence.  The  question  then  becomes  one  of  creating  a 
model  which  is  both  epistemologically  and  heuristically  adequate  (following  McCarthy 
and  Hayes).  In  other  words,  the  aim  is  to  use  just  enough  knowledge  and  just  enough 
search  to  obtain  successful  and  interesting  results. 
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Important  innovations  in  representing  planning  knowledge  which  emerged  from 
PGSC’s  second-phase  effort  center  upon  1 )  the  use  of  search  as  a  form  of  knowledge 
and  2)  a  framework  for  representing  this  explicitly. 

The  phase-two  planner,  ARES,  builds  plans  by  engaging  a  given  world 
situation  or  environment  in  a  planning  dialectic.  The  plans  are  constructed  out  of 
generic  goal  structures  representing  generalized  planning  knowledge  about  the 
domain.  Based  on  the  system’s  analysis  of  the  current  world  situation,  these  general 
pieces  of  knowledge  are  informed  and  related  into  a  network  of  specified  goals.  In  the 
current  implementation,  uninformed  goals  are  s-expressions  in  the  LISP  Language. 
Each  goal  has  a  number  of  properties  which  are  slots  in  the  atom’s  property  list.  The 
goal  name  identifies  the  atom  or  s-expression.  The  property  slots  include  the 
following: 

(1)  COUNTERGOAL  --  an  assumed  adversarial  countergoal, 

(2)  SUBGOAL  --  a  list  of  possible  subgoals  for  when  the  agent  is  the  curren* 
actor  in  the  environment, 

(3)  SUB_NOT_ON_MOVE  -  a  list  of  possible  subgoals  for  when  agent  is  not 
the  current  actor  in  the  environment, 

(4)  FEASIBLE  -  a  list  of  feasibility  conditions, 

(5)  SUCCESS  --  a  list  of  success  conditions,  and 

(6)  FAILURE  --  a  list  of  failure  conditions. 

While  a  value  or  list  is  initially  attached  to  each  uninformed  goal,  these  values 
are  used  only  as  a  starting  point  for  producing  specified  or  filled-in  attachments  as  the 
goal  is  developed  during  the  course  of  a  planning  sequence. 

PGSC  distinguishes  between  informed  and  uninformed  goals  on  the  basis  of  a 
specification  which  is  necessary  in  order  to  instantiate  a  particular  goal.  An  informed 
goal  is  defined  as  a  goal  which  has  been  developed  in  a  context-sensitive  fashion  by 
transforming  its  initial  attachments  or  properties  into  specified  attachments.  The 
difference  between  an  uninformed  goal  and  an  informed  goal  is  illustrated  as  follows. 
Imagine  a  human  planner  operating  in  a  tactical  combat  situation.  The  planner  has  a 
number  of  general-purpose  maneuvers  or  “goals"  which  he  can  use,  given  varying 
circumstances  --  an  example  would  be  “march  to  contact."  As  such,  this  operation 
would  be  similar  to  what  we  are  calling  an  uninformed  goal  —  it  is  devoid  of  any 
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contextualizing  circumstances  and  lacks  “filling-in."  Once  the  planner  chooses  to 
pursue  the  goal,  however,  he  decides  to  march  some  particular  set  of  forces  to  contact 
with  some  adversary  at  a  given  point  and  time.  In  this  way  the  goal  becomes  specified 
or  informed. 

The  actual  filling-in  of  an  uninformed  goal  occurs  when,  in  the  development  of  a 
Contingency  Goal  Tree  (CGT),  ARES  expands  an  existing  node.  In  planning,  not  only 
must  an  agent's  plan  be  consistent  between  levels  of  abstraction  (see  Section  2),  but 
also  the  agent’s  model  of  its  adversaries'  countergoals  and  the  success/failure  tests  for 
the  goal  must  reflect  this  same  consistency.  Thus,  while  an  agenfs  goal  of  "CAPTURE 
(X)’  might  be  generally  paired  with  and  adversarial  countergoa!  of  “DEFEND  (X).“  it  is 
not  necessary  that  in  a  specific  situation  the  adversary  have  that  countergoal.  It  might 
be  the  case  that  in  the  parent  node  the  adversary’s  countergoal  was  NIL  (incficating 
that  ARES  expects  the  adversary  to  ignore  its  goal),  and,  therefore,  it  makes  no  sense 
for  there  to  be  a  countergoal  of  any  child  of  that  node. 

ARES  specifies  the  countergoal  attachment  by  conjoining  the  set  of  generic 
countergoal  attachments  for  the  goal  with  the  specified  or  informed  set  of  counter¬ 
subgoals  from  the  parent,  thereby  making  sure  that  each  step  in  the  adversary's 
counterplan  is  consistent  with  its  predecessor.  Similarly,  it  is  3iso  necessary  to  make 
sure  that  the  success  or  failure  tests  of  any  node  rn  a  network  include  consideration  of 
the  parent  nodes.  This  is  because,  for  ARES,  the  planning  of  a  move/countermove 
sequence  is  dependent  upon  the  ability  to  recognize  success  or  failure  across  levels 
of  hierarchical  abstraction.  As  an  example,  consider  the  case  depicted  by  the  move 
tree  in  Figure  4-1 .  This  example  is  taken  from  the  game  of  Othelio  (see  the  detailed 
description  of  ARES’  behavior  in  this  domain  that  follows).  The  planner's  goal  is  to 
occupy  comer  X,  and  the  assumed  countergoa1  is  also  to  occupy  X.  To  occupy  corner 
X,  ARES  has  identified  CTRL(AX)  as  a  subgoa!  which  is  paired  with  CTRL(AX)  as  a 
counter.  Since  AX  is  already  occupied  by  an  adversaria!  piece,  the  only  way  it  can  be 
occupied  by  ARES  is  to  flip  or  turn  the  piece  over.  TURN_pVER(AX),  then,  becomes 
ARES'  next  subgoal  with  a  countergoa!  of  TURN_OVFR(AX). 

The  knowledge  base  assumes  that,  if  the  agent's  objective  is  to  turn  over  a 
piece,  the  adversary  will  want  to  turn  the  piece  back  over  again.  ARES  first  makes 
move  1 ,  which  flips  AX  over.  Next,  playing  for  the  adversary,  ARES  finds  move  2, 
which  will  flip  AX  over  agan  (back  to  its  original  configuration).  Move  2  just  happens 
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to  be  a  play  into  corner  X,  however,  and,  by  making  this  move,  the  adversary  would  be 
able  to  thwart  ARES’  level-1  goal  of  controlling  that  corner.  It  therefore  makes  no 
sense  for  ARES  to  consider  this  sequence  any  further  -  it  is  a  bad  plan.  ARES  can 
only  realize  this  based  on  a  failure-conditions  analysis  which  it  would  make  before 
processing  the  next  goal  (a  potential  move  3). 


The  specified  failure  lists,  used  to  determine  when  some  sequence  represents  a 
bad  plan,  results  from  the  conjunction  of  the  generic  goal  attachments  of  the  goal  as  it 
is  in  its  uninformed  state  with  the  set  of  all  specified  failure  conditions  from  parent 
goals  in  the  same  path.  Thus,  ARES  has  encountered  a  failure  if  the  white  side  has 
turned  over  ( <\X)  and  white  occupies  (X). 


OTHELLO  Move  -’ree 
Figure  4-1 
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5.  OTHELLO  EXAMPLE 


This  section  presents  a  detailed  example  of  an  '  RES  planning  sequence  from 
the  popular  two-player,  perfect-information  game  Otheii  Othello  is  played  on  a  board 
of  64  squares  (8  x  8).  Two  colors  of  stones  (white  and  black)  are  used  for  the 
respective  players.  The  object  of  the  game  is  for  a  player  to  occupy  more  squares  with 
his  color  of  stones  than  the  opponent.  A  square  is  captured  by  outflanking  an 
opponents  stone  (or  a  row  of  stones).  Outflanking  is  accomplished  by  being  able  to 
make  a  play  such  than  an  opponent’s  stone(s)  is(are)  enclosed  by  two  friendly  stones, 
one  at  each  end.  The  following  is  an  illustration: 

ABODE 

©•#•© 

White  has  Stone  1  at  Position  A,  and  Position  E  is  open.  By  playing  a  stone  at  Position 
E,  white  is  able  to  outflank  the  three  black  stones  located  at  B,  C,  and  D.  A  player 
(either  white  or  black)  is  able  to  make  a  valid  play  any  time  a  stone  can  be  placed  in 
such  a  fashion  so  as  to  outflank  one  or  more  of  the  opponent’s  stones.  Once  such  a 
play  is  made,  the  opponent’s  stones  in  the  intervening  spaces  are  “flipped,”  that  is  they 
are  changed  to  stones  of  the  color  of  the  player  making  the  outflanking  play.  For 
instance,  in  the  example  shown  above,  once  white  played  Stone  2  at  Position  E,  the 
black  stones  at  Positions  B,  C,  and  D  would  be  changed  to  white  stones.  If  a  player 
cannot  make  an  outflanking  play,  he  must  “pass”  on  that  turn  and  wait  for  anothe  r 
opportunity.  The  game  ends  when  all  of  the  spaces  on  the  board  are  occupied  by 
stones.  The  player  whose  color  stones  occupy  the  majority  of  spaces  wins.  In  the 
computer  implementation  of  Othello  which  has  been  built  for  demonstrating  the 
planner,  the  computer  plays  for  one  side  against  a  person  (or  itself).  The  planner 
plays  for  the  white  side  and  the  opponent  plays  for  black.  The  initial  configuration  of 
the  sixty-four  (8  x  8)  square  game  board  is  as  shown  in  Figure  5-1.  Two  black  stones 
and  two  white  stones  are  initially  placed  in  the  center  of  the  board.  Black  (the 
opponent)  is  allowed  to  move  first.  In  the  example,  which  is  taken  from  an  actual 
game,  the  moves  of  the  planner  (white)  will  be  explained  in  terms  of  the  contingency- 
goal  trees  used  to  arrive  at  those  moves.  To  make  the  planning  sequence  more 
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interesting,  a  number  of  moves  already  played  b' '  both  the  black  and  white  sides  have 
resulted  in  the  configuration  of  the  playing  board  shown  in  Figure  5-2. 

Figure  4-1  showed  the  current  contingency-go^'  *reb  that  the  p’^ner  is 
considering  In  the  bottom  left  corner  of  the  board,  white,  which  in  this  case  is  AREC, 
has  a.  play  which  wi.i  allow  it  to  occupy  Square  (C6),  whhh  is  two  squares  away  from 
the  Corner  (A8),  tnus  satisfying  the  Subgoal  "ctrl_l_2_away".  Having  found  this  move, 
ARES  plays  it  cn  a  hyooihetical-move  board  ,e  Figure  5-3)  and  then  switches  sides 
to  play  for  black  to  see  if  there  is  an  adversarial  cuuntergoal  which  will  be  achievable 
as  a  result  of  ARES’  move.  Black’s  assumed  countergoal  of  white’s  “play"  is  “NIL,” 
and  so  ARES  (playing  tor  black)  backs  up  the  tree  one  level  to  the  parent  to  check  the 
countergoal  there.  The  parent  goal  to  ARES  "play”  is  “piay_safe_(C6),”  and  the 
assumed  adversaria!  countergoal  is  also  “piay_safe_(C6).’’  “Phy_safe”  is  a  goal 
object  defined  such  that  a  play  will  be  r  lade  on  a  given  square  am  the  opponent  will 
not  be  able  to  turn  the  stone  over.  Jlack  now  has  the  countergoal  of  trying  to  occupy 
(C6).  It  can  accomplish  this  in  cne  oi  two  ways:  1)  play  on  the  space  if  it  is  not 
occupied  and  represent3  a  valid  move,  or  2)  attempt  to  turn  over  an  opponent’s  piece 
occupying  the  position.  Since  white  is  (In  the  hypothetical-move  environment) 
occupying  (C6),  black’s  only  hope  is  to  attempt  to  turn  over  that  piece.  Since  a  black 
play  at  (C7)  will  a’icw  it  to  do  so,  ARES  makes  this  play  for  black  on  a  new 
hypothetical-movb  board  (see  Figure  5-4).  ARES  now  switches  back  to  its  side  again 
and  considers  the  most  recently  added  node  to  the  CGT  (the  black  play  at  (C7)). 
Since  the  countergoal  of  the  black  play  is  “NIL,1  ARES  backs  up  to  the  black  parent 
goal  of  ,‘turn_pver_(C6),”  the  countergoal  of  which  is  also  “tum_over_(C6).’’  ARES 
now  attempts  to  find  a  new  white  play  which  will  result  in  the  turnover  of  (C6).  A  play  at 
(B6)  is  such  a  move  and  so,  as  before,  a  new  hypothetical  board  ij  created  and  ARES’ 
new  move  is  played  on  It  (see  Figure  5-5).  APES  switches  sides  back  to  black  and 
backs  up  as  before  to  white’s  goal  of  “turn_over_(C6),”  which  is  paired  witr 
“tum_over_(G6)n  as  a  countergoal.  Since  black  has  a  play  at  (A6)  which  will  turn  (C6) 
over  again,  this  move  is  played  on  a  fypothetical-move  board  at  yet  another  level 
(Figure  5-6).  Switching  back  to  white,  ARES  locates  another  move,  at  (B7),  which  will 
flip  the  target  place  (C6)  back,  and  this  play  is  made  on  the  next-level  hypothetical- 
move  board  (Figure  5-7).  Another  switch  is  made  to  the  black  side, with  ARES  backing 
up  as  before  the  the  “turn_o>/er_(C6)”  goal.  Black  now  has  a  play  at  (A8),  which  will 
flip  (C6)  over  again,  and  this  move  is,  in  turn,  played  on  a  hypothetical-move  boara 
(Figure  5-8).  At  this  point,  ARES  does  not  yet  realize  that  implicit  in  black’s  play  at  (A8) 


5-3 


5-4 


Figure  5-3  Figure  f 


5-5 


04  CO  rt  If)  0  N  CO 

5-6 


is  the  automatic  failure  of  its  upper-level  goal  of  “improve_corner_(A8),”  arid  so  it 
switches  sides  back  to  white  and  backs  up  the  tree  to  the  turnover  goal.  Examining  the 
success/failure  conditions  for  this  node,  ARES  finds  that,  since  black  has  occupied  the 
corner  at  (A8),  the  opponent  has  succeeded  in  defeating  white’s  objective.  It  does  no 
good  to  continue  to  attempt  to  turn  over  (C6),  since  the  whole  point  of  this  play  was  to 
set  up  the  corner  at  (A8)  and  this  present  contingency  has  resulted  in  the  loss  of  the 
target  corner. 

It  is  important  to  notice  that,  without  the  success/failure  tests,  ARES  would  have 
gone  ahead  looking  for  move  sequences  that  would  allow  it  to  occupy  (C6)  and  would 
not  have  known  that  any  move  sequence  that  allows  black  to  occupy  the  corner,  even 
if  it  results  in  the  success  of  the  subgoal,  is  a  greater  success  for  the  opponent.  Having 
realized  this  implicit  failure,  however,  ARES  begins  to  replan.  The  first  step  is  to  pop 
back  up  two  levels  in  hypothetical  worlds,  returning  to  the  situation  before  it  made  the 
play  at  (B7)  which  led  to  the  situation  of  black  occupying  the  corner  at  (A8)  (See 
Figure  5-6).  Now  ARES  proceeds  to  plan  for  white  with  a  new  goal  of  turning  over 
(C6)  AND  NOT  playing  at  (B7).  As  is  evident  from  an  inspection  of  Board  5  (Figure  5- 
6),  there  are  no  white  moves  other  than  (B7)  that  will  flip  C6  over.  Thus,  ARES  must 
search  back  even  further,  popping  up  another  two  levels  in  boards  to  where  it  was 
before  it  played  at  (B6)  (see  Figure  5-4).  At  this  point  its  goal  is  to  turn  over  (C6)  AND 
NOT  play  (B6).  Here,  ARES  has  another  alternative:  it  can  achieve  this  goal  by 
playing  at  (B7).  It  may  seem  peculiar  that  such  a  move  would  be  considered  since  it 
was  a  similar  play  at  (B7)  which  allowed  black  to  occupy  the  corner  in  an  earlier 
contingency,  but  there  is  no  necessary  reason  to  assume  that  by  introducing  it  now,  a 
similar  failure  will  occur  (even  though  that  is  exactly  what  happens).  Having 
discovered  this  new  move,  ARES  proceeds  to  create  a  new  level  of  hypothetical-move 
board  (see  Figure  5-9)  and  places  this  move  on  it.  Switching  sides  as  before  and 
backing  up  the  goal  tree  for  white,  ARES  is  now  looking  for  a  move  which  will  turn  (C6) 
back  over.  It  discovers,  as  before,  that  by  playing  at  (A8)  it  can  turn  the  piece  in 
question  (C6)  over  once  again  (see  Figure  5-10).  As  before,  after  switching  sides  and 
checking  its  success/failure  tests  AREAS  finds  that  its  upper  level  goal  has  failed  and 
so  it  must  once  again  attempt  to  replan.  Levels  of  hypothetical-mm/e  boards  are 
backed  up  to  the  situation  as  it  was  before  ARES  played  at  (B7)  (see  Figure  5-4).  Now 
the  goal  is  to  turn  over  (C6)  AND  NOT  play  (B6)  AND  NOT  play  (B7).  As  is  obvious 
from  the  game-board  diagram,  there  are  no  available  moves  which  will  allow  this  goal 
to  be  achieved.  ARES,  therefore,  pops  up  two  more  levels  in  hypothetical-move 
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boards  to  the  situation  as  it  was  before  it  played  at  (C6).  As  there  are  no  other  moves 
that  will  allow  ARES  to  occupy  this  square  (C6),  it  abandons  this  target  and  will  instead 
try  to  see  if  there  is  another  way  in  which  it  can  improve  its  position  in  this  corner. 
ARES  will  continue  to  consider  move-countermove  sequences  until  it  finds  a  winning 
combination  for  itself  which  black  cannot  counter.  The  move/countermove  tree  that  is 
finally  developed  becomes  ARES  current  strategic  plan.  The  other  contingency  trees 
are  maintained  along  with  their  corresponding  hypothetical-move  boards.  When  black 
next  moves,  ARES  will  compare  the  adversarial  action  with  its  current  strategic  plan  to 
see  if  the  adversary  is  behaving  as  anticipated.  If  black’s  move  corresponds  to  ARES’ 
calculated  best  move  for  black,  the  current  tactical  plan  is  still  valid  and  ARES  can 
automatically  make  its  next  move  as  indicated  in  the  plan.  If  black’s  move  does  not 
correspond  to  what  ARES  expected  black  to  do,  it  is  possible  that  one  of  the  following 
conditions  exists: 

1 .  The  adversary  is  unaware  of  ARES  tactical  plan  or  has  abandoned  the 
target  and  will  not  react  to  ARES’  offensive,  or 

2.  The  adversary  is  aware  of  ARES’  tactical  objective  but  has  failed  to  identify 
the  best  move  sequence  to  thwart  the  plan,  or 

3.  ARES  has  made  an  error  in  the  assumption  of  adversarial  countergoals. 

ARES  first  considers  that  Case  2  is  indeed  what  has  happened  and  it  searches 
through  its  collection  of  stored  CGTs  and  hypothetical-move  boards  to  see  if  black  may 
have  blundered  and  selected  a  poor  countermove.  If  the  given  scenario  is  located 
among  the  stored  CGTs,  the  located  CGT  is  used  to  update  the  current  tactical  plan 
according  to  the  new  move  sequence  contained  in  the  tree.  Because  ARES  has 
already  thoroughly  examined  this  tree,  beginning  with  black’s  countermove,  it  is  just  as 
certain  that  black  will  fail  in  this  sequence  as  it  was  in  the  original  tactical  plan. 

If,  on  the  other  hand,  ARES  is  unable  to  locate  the  black  counter  among  its 
stored  CGTs,  it  immediately  begins  to  develop  a  new  tactical  plan,  taking  into 
consideration  the  new  situation  resulting  from  black’s  unexpected  countermove.  By 
proceeding  in  this  way,  ARES  is  able  to  deal  effectively  with  the  possibility  that  the 
adversary  may  have  abandoned  ARES’  tactical  target,  or  may  be  embarking  on  some 
offensive  of  its  own.  In  this  case  it  is  necessary  for  ARES  to  rethink  a  tactical  plan 
given  the  possibility  that  its  opponent  may  have  changed  the  environment  in  such  a 
way  so  as  to  be  posing  a  serious  challenge  in  some  other  part  of  the  game  board. 
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Such  a  reconsideration  does  not  automatically  mean  that  the  original  tactical  plan  will 
be  abandoned,  only  that  other  alternatives  will  be  considered  in  light  of  the 
adversary’s  new  action,  and,  if  the  original  tactical  plan  is  no  longer  the  most 
advantageous  for  realizing  higher-level  statistic  goals,  a  new  tactical  plan  will  be 
developed. 
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6.  MANEUVER  EXAMPLE 


In  addition  to  refining  and  formalizing  the  work  conducted  in  Phase  I,  the  Phase 
II  effort  extended  the  adversarial-planning  mechanism  from  the  two-player,  perfect- 
information,  sequential-movement  domains  examined  (primarily  Othello)  to  a  more 
robust  and  realistic  environment.  Since  the  ultimate  goal  was  a  planner  that  can 
effectively  operate  in  battlefield  environments,  the  researchers  decided  to  create  a 
simple  corps-maneuver-planning  scenario  as  the  target  domain. 

The  school  scenario  used  at  the  U.S.  Army  Command  and  General  Staff 
College,  Ft.  Leavenworth,  KS,  was  selected  as  a  basis  for  the  new  planning  domain. 
A  wargame  consisting  of  seven  distinct  maneuver  units  was  abstracted  from  the 
detailed  scenario.  This  generalized  scenario  is  depicted  in  Figure  6-1.  The  following 
extract  from  the  Corps  operations  text  (lesson  3)  describes  the  scenario  the  research 
effort  attempted  to  plan. 

“The  corps  main  attack  will  concentrate  in  the  south  (right)  to 
defeat  the  1  GTA  by  rapid  penetration  of  its  main  and  second  defense 
belts  thus  destroying  the  continuity  of  threat  defense  and  rear  services 
systems.  The  corps  attack  will  be  conducted  with  three  mechanized 
divisions  attacking  in  sequence  from  north  to  south.  At  D-day,  H-hour, 
the  54th  Mech  Div  attacks  in  the  north  (left);  at  H+12,  the  53rd  Mech  Div 
attacks  in  the  center.  The  52nd  Mech  Div  is  the  corps  main  effort  and 
attacks  at  H+14  in  the  south  (right).  The  sequence  of  the  corps  attack  is 
designed  to  cause  the  TRs  in  the  second  defense  belt  to  shift  north  from 
present  positions  against  the  supporting  attacks  in  the  north,  thus 
reducing  the  strength  of  threat  forces  in  the  zone  of  the  main  attack  (52nd 
Mech  Div).  The  54th  Mech  Div  will  attack  through  the  23rd  Amd  Div  on 
the  left  (north)  to  penetrate  the  main  defense  belt,  then  continue  the 
attack  to  penetrate  the  second  defense  belt,  fix  the  55  TR  in  zone  if  it 
counterattacks,  and  secure  objective  1  (NB2940).  The  53rd  Mech  Div 
attacks  through  elements  of  the  23rd  Armd  Div  and  208th  ACR  in  the 
center  to  penetrate  the  main  defense  belt,  fix  the  115  TR,  &  TD,  if  it  is 
employed  in  zone;  then  secure  objective  2  (NB4127).  The  52nd  Mech 
Div,  the  main  attack  on  the  right  (south),  attacks  to  penetrate  the  main 
defense  belt,  then  maneuvers  to  secure  objective  3  (NB5920).  In  the 
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event  that  threat  forces  do  not  shift  north  as  expected,  the  main  effort  will 
be  redesignated  to  the  54th  Mech  Div  or  the  53rd  Mech  Div. 

“The  corps  flanks  will  be  protected  by  the  CENTAG  supporting 
attacks  along  each  flank.  The  54th  Mech  Div  will  prepare  to  protect  the 
corps  northern  flank  (left)  with  the  priority  between  PL  HORSE  and  PL 
SHARK;  the  52nd  Mech  Div  will  prepare  to  protect  the  corps  southern 
flank  (right)  from  PL  ELK  to  PL  SHARK. 

“The  54th  Mech  Div  and  53rd  Mech  Div  relieve  friendly  defending 
units,  in  zone,  of  responsibility  for  containment  of  threat  forces  along  the 
LD/LC  by  H+14  and  H+18,  respectively.  The  attacking  divisions  will 
prepare  to  assist  the  rapid  passage  of  exploiting  forces  as  soon  as  the 
assigned  objective  is  secure.  The  208th  ACR  prepares  to  follow  the  54th 
Mech  and  53rd  Mech  Divs,  in  zone,  in  order  to  initiate  phase  II  of  the 
corps  operation  by  a  rapid  passage  and  exploitation.  The  25tn  Armd  Div 
prepares  to  follow  the  52nd  Mech  Div  or  53rd  Mech  Div,  in  zone,  in  order 
to  execute  phase  II  of  the  corps  plan." 

To  simulate  this  problem  the  planning  mechanism  was  adjusted  to  generate 
plans  of  attack  for  multiple  units,  each  capable  of  a  variety  of  independent  actions  at 
different  times.  Here,  the  major  difference  from  the  prior  implementation  is  that  a 
single  “move”  for  either  the  friendly  or  adversary  side  consists  of  a  coordinated  action 
of  several  pieces  (more  than  one  unit).  Each  of  these  coordinated  actions  can  be 
countered  by  multiple  enemy  responses.  As  before,  an  appropriate  response 
consisting  of  some  combination  of  unit  actions  is  postulated  as  a  contingency  plan  and 
tested  hypothetically  through  CGT  generation  to  see  how  that  possible  response  will 
fare  against  possible  counters.  Once  an  appropriate  response  is  located  the  planner 
posts  the  action  and  updates  the  simulation.  Planning  is  then  undertaken  for  the  other 
side. 


In  order  to  decide  the  relative  advantage  or  disadvantage  of  any  particular 
course  of  action,  a  simple  outcome  simulator  was  employed  to  calculate  the  extent  to 
which  a  given  unit  either  defeated  or  was  weakened  by  any  unit  with  which  it  came  in 
contact.  Failed  courses  of  action  for  either  side  arose  whenever  an  engagement  led  to 
such  a  diminishment  of  the  friendly  force  that  a  breakthrough  could  not  be  prevented. 


6-2 


A  prototype  knowledge  base  of  goals  and  countergoals  for  the  domain  was 
created  by  knowledge-engineering  activities  conducted  internally  at  PGSC.  In 
addition,  the  Leavenworth  course  materials  for  the  modeled  domain  provided  an 
additional  source  of  both  friendly  and  adversary  goals. 

The  remainder  of  this  section  depicts  the  actual  planning  sequence  conducted 
by  ARES  in  the  corps-maneuver  domain.  In  the  series  of  storyboards  which  follow, 
each  space  is  occupied  by  a  token.  The  storyboards  are  numbered  (1-16),  and  a 
script  for  interpreting  the  planning  sequence  follows: 


(1)  Starting  positions.  Friendly  force  on  left,  OPFOR  on  right.  OPFOR  goal  is 
to  find  an  offensive  plan  against  which  the  friendly  force  cannot  defend. 

(2)  First  contingency  plan  considers  a  single  massive  attack  through  the 
central  gap. 

(3)  Friendly  attempts  to  counter  with  a  shallow  defense. 

(4)  After  1 2  hours,  friendly  force  has  lost  one  unit  and  others  are  weakened. 

(5)  After  24  hours,  battle  is  still  continuing  in  central  gap,  friendly  forces  are 
further  weakened. 

(6)  After  36  hours,  OPFOR  breaks  through  on  southern  edge  of  gap. 

(7)  After  48  hours,  the  friendly  defense  has  clearly  failed.  Planner  will  now 
back  up  and  attempt  to  plan  another  defense  against  the  OPFOR’s  single 
massive  attack. 

(8)  Alternative  friendly  defense  will  be  defense  in  depth  (using  a  24-hour 
decision  cycle). 

(9)  After  24  hours,  OPFOR  makes  initial  breakthrough  in  northern  region  of 
the  gap. 

(10)  After  48  hours,  friendly  tank  division  has  moved  up  from  the  southwest  to 
challenge  advancing  OPFOR  divisions.  Defense  holds  and  a  satisfactory 
plan  has  been  discovered  that  can  stop  single  massive  attack  by  OPFOR. 
Planner  now  backs  up  and  attempts  to  replan  for  OPFOR. 

(1 1 )  New  contingency  plan  for  OPFOR  utilizes  dual  avenues  of  approach. 

(12)  Friendly  force  counters  with  defense  in  depth. 
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(1 3)  Friendly  force  is  weakening  in  area  of  lower  OPFOR  thrust. 

(14)  Friendly  tank  division  moves  in  to  meet  advancing  OPFOR  along  lower 
prong. 

(1 5)  OPFOR  breaks  through  in  the  north. 

(16)  OPFOR  advance  continues  in  the  north.  Friendly  defense  has  failed. 
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7.  SUMMARY 


The  original  goals  of  the  Phase  II  effort  were: 

1 .  Develop  a  Plan  Language  for  Pattern-directed  Planning, 

2.  Develop  a  Plan  Language  for  Robot  Planning, 

3.  Investigate  Adversarial  Planning  Issues  in  Robot  Problem  Solving, 

4.  Extend  the  planning  system  to  multi-agent  domains,  and 

5.  Investigate  approaches  to  interactive  Planning. 

All  of  these  objectives  have  been  achieved  to  a  certain  extent.  The  most 
significant  success  was  the  extension  of  the  planning  mechanism  to  the  corps- 
maneuver  problems,  which  involved  both  multiple  agents  (Goal  #4)  and  interactive 
planning  (Goal  #5).  Unfortunately,  the  researchers  discovered  that  adversarial 
contingency  planning  is  not  as  appropriate  in  low-level,  reactive  domains  such  as 
robotics  as  it  is  in  higher-level,  more-strategic  environments.  This  is  undoubtedly  due 
to  the  fact  that  the  search  space  examined  by  the  planner,  although  a  mere  fraction  of 
that  examined  by  other  planners,  is  yet  sizable  enough  to  require  significant  time  for 
computation. 

The  efforts  to  develop  a  planning  “language”  were  also  successful  in  that  a 
generic  plan  parser  was  defined  which  is  capable  of  developing  plans  of  action  based 
on  input  goals  which  can  represent  actions  in  any  pre-defined  domain. 

Possibilities  for  further  research  can  best  be  broken  down  into  two  areas.  First, 
the  basic  features  of  the  planner’s  goal  representation  could  easily  be  formalized  into 
a  grammar  which  would  allow  for  easier  processing  and  manipulation  of  success  and 
failure  tests.  Currently,  these  tests  are  being  added  to  long  lists  that  develop  as  a 
particular  course  of  action  develops.  Such  a  grammar  would  make  it  possible  to  make 
these  lists  more  manageable  and  to  reduce  backtracking;  deKleer  (1985)  suggests 
such  a  grammar. 

A  second  possibility  for  further  research  is  in  the  area  of  distributed  or  parallel 
planning.  Currently,  the  planning  process  is  understood  in  terms  of  a  sequential  linear 
model.  Real-life  planning  in  such  domains  as  Command  and  Control,  however,  is 
conducted  in  parallel.  The  primary  problem  is  the  difficulty  in  knowing  how  to  partition 
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planning  bases  so  as  to  make  them  independent.  If  they  are  not  treated  as 
independent,  knowing  how  changes  in  the  situation  affect  different  components  is 
difficult.  Essentially  the  problem  is  knowing  what  information  is  important  to  a  planner 
working  on  some  sub-problem. 
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APPENDIX  A 


PROGRAM  1 


DEMONSTRATION  INSTRUCTION 


1FL ( : BYTE-S IZE  B  : LENGTH- IN-BLOCKS  4  : LENGTH- IN-BYTES  3789 
iAME •  JNAME  *ADEMOINST“  :type  “L*  VERSION  3) 


JTHOR  *  WARGAME 1  :  GREAT  I 


■^STRUCT IONS  FOR  RUNNING  A  DEMCNSTRAT ION  OF  ARES  FOR  THE  WARGAME 
—  SETTING  UP  THE  DEMONSTRATION 

(1)  in  the  lisp  interpreter  enter  1  (login  'wargame)1 

(2)  then  enter  •<dired),f  you  should  then  see  a  listing 
of  the  top  level  directory  for  “wargame11 

(3)  using  the  mouse  (left  button)  select  the  file  'af malgame. 1 ' 

(4)  then  enter  “E*,  this  will  load  the  editor ,  load  the  file 
into  a  buffer*  and  oner*  the  buffered  file  for  editing 

(5)  once  in  the  editor  enter  *META-xB,  this  will  allow  you 

to  enter  extended  command  (look  at  window  at  bottom  of 

>t'  screen) 

(6)  enter  •compile  buffer*  and  return,  this  will  compile  the  present 
buffer  into  the  lisp  environment 

(7)  after  compilation  is  complete  enter  * META-CTFL-I B *  this  will 
return  you  to  the  directory 

(8)  repeat  steps  (3)  to  (7)  above  for  the  following  files  in  order: 

7  af  inalterr am .  1 7 
'af inalgoaldef .1 7 
'  af inalge^is.  1 ' 

(9)  repeat  steps  (3)  xo  \o)  for  the  file  ' af inalares . 1  ' 

(10)  after  step  (9)  all  necessary  files  for  execution  should  be  compiled 
into  the  lisp  environment  and  you  should  still  be  in  the  buffer 

■ af inalares .  1 7 

(11)  while  the  arrow  is  m  the  main  window  hit  the  right  button,  when  the 
menu  appears  thake  the  option  'Kill  or  Save  Buffers',  when  in 

this  option  kill  the  buffers  ' af inalgame. 1 ' ,  7  af  malgoal  a  .  1 '  , 

' af inalgoaldef • 1 ' .  and  ' af inalter rain . 1 ' •  While  this  step  is 

optional  the  planner  has  a  tendency  to  overload  virtual  memory. 

Doing  this  step  will  avoid  this  problem  during  a  demo! 

(12)  while  in  the  file  ' af inalares* 1 '  enter  “BREAK*,  this  will  open  up 
a  window  into  the  lisp  environment 

(13)  enter  “(display  realboard  t)“,  this  will  clear  the  screen  and  display  the 
present  board  position 

(14)  enter  “ (retr ieve_game  ' ademogame . 1 ) “  ,  this  step  is  optional  but  will  cut 
your  demo  down  from  two  hours  to  10  minutes,  m  particular  this  file 
contains  the  results  of  previous  path  finding  problems  making  it  unnessecar* 
to  wait  while  the  system  does  path  finding. 

(15)  enter  B(plan  fgoal  egoal  t)“,  this  will  start  the  planner  going 

(16)  after  each  new  board  position,  the  planner  will  break.  you  may  find  the 
following  commands  useful: 

(a)  “RESUME*  --  this  will  exit  the  break  and  continue  the  planning  sessior 
<b)  • (display_orders  7hypbo3rd  S)*  where  S  can  be  “friend*  or  *^nemy“ 
this  will  display  the  most  recent  orders  to  either  side 

(c)  1 ( display_um t_status  'hypboard  U)B  where  U  is  any  unit  identifier 

this  will  display  the  present  status  of  any  unit 

(d)  “(pprmt  (reverse  (first  cgt)))“  —  this  will  display  all  ooals 

the  planner  processed  to  get  to  the  present  position  for  side  friend 

(e)  “(pprmt  (reverse  (second  cgt)))“  --  same  as  (d)  for  side  enemy 
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(17) 


(18) 

(19) 

(20) 
(21) 
(22) 


(f)  "CLEARSCREEN"  useful  to  do  before  (d) 

(g)  "(cursorpos  50)*  moves  the  cursor  just 

(h)  "(display  hypboard  t)1  —  redisplays 

board  position 

note  that  the  planner  is  quite  fast  except 
arid  restarts  usually  take  3-5  minutes  (JIM 
when  we  get  back  to  work  > 

when  everything  is  finished  enter  "ABORT" , 
in  the  'afinalares.l'  buffer 
enter  "SYSTEM-L"  this  will  put  you  back  m 
in  the  lisp  listener  enter  "(logout)" 
enter  "(siSZhalt)" 

proceed  to  turn  of  the  LMABEiA  machine 


or  ( e ) 

under  the  board 

the  present  hypothetical 

when  it  does  a  backup,  backups 
we  can  cut  this  to  a  few  seconds 

this  will  put  you  back 

the  top  level  lisp  listener 
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PROGRAM  2 


TERRAIN 


LHFL ( JBYTE-S IZE  8  : LENGTH- IN- BLOCKS  11  : LENGTH- IN-BYTES  11151  : AUTHOR  * WARGAME*  :CI 
WARGAHE-  INAHE  * AF INALTERRA IN #  :TYPE  "L1  ZVERSION  1) 


;  this  file  contains  an  example  game 

;  a  game  includes  a  terrain_board  and  a  set  of  units 

;  for  each  side 

(defvar  terr ain_boar d  nil) 

;  terrain_board  will  be  a  global  variable  that  defines 
;  the  board 

;  the  following  is  how  the  terrain  board  is  defined 
(setq  terr ain^board 
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in 

additions 

to  the 

terrain  itself  that  are 

a  number  of 

features  of 

a  board 

that  are  looked  at  by  the  knowledge  base 
these  features  are  defined  a  properties  below 
corridors  of  attack  are  defined  below 

in  the  terrain  board  defined  above  there  are  four  corridors 
for  each  corridor  the  following  things  are  identified 

def end-points  lists  of  sets  of  defensive  points  for  each  side 
forward  most  defend  points  are  listed  first 
paths  lists  the  alternative  oaths  of  attack  for 

at  present  these  paths  are  the  same  for  both  sides 
but  this  should  later  be  changed 

general-area  is  a  list  of  all  unit  locations  in  the  general  area 
of  the  corridor 

(outcrop  'defend-points  '(  (friend  <  ((53))  ((63)))) 

(enemy  (  ((7  3)>  ((6  3)>)>> 
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'corr idorl ) 

(putprop  'paths  '(  ((5  3)  (6  4)  (7  3))  ((5  3)  (6  2)  (7  2)  > 

( <5  3)  (63)  (74))) 

'corr idorl ) 

(putprop  'general_area  '(  (4  2)  (4  3)  < 4  4)  (5  2)  (5  3)  (5  4)  <6  2)  (6  3)  (6  4) 

(7  2)  <7  3)  (7  4)  <8  2)  <8  3)  (8  4>> 

'corridorl ) 

(putprop  'center  point  '(6  3)  'corridorl) 

(putprop  'defend^ points  ' <  (friend  (  ((5  5)  (5  6>>  ((6  5)  '5  6) )  ((5  5)  (6  6)) 
((65)  (66))  )  ) 

(enemy  (  (<7  6)  <S  5))  ((7  6)  (7  5))  <(7  6)  (6  5))  >  )) 

'corridor2> 

(putprop  'paths  '<  ((5  5)  (6  5)  (7  5))  ((5  6)  <6  7)  (7  6))  <(5  6)  <6  6)  (7  7>)> 
'corr idor 2  > 

(putorop  'general-area  '(  (4  5>  (4  6)  (4  7)  (5  5)  (5  6)  (5  7) 

(65)  (6  6)  <6  7)  (7  5)  (7  6)  (7  7) 

(35)  (86)  (87)  (95)  (96’  (97)  ) 


'corridors ) 

(putprop  ' center ^point  '(6  6;  'corridorS) 

(putprop  ' def end-points  '  ■.  'friend  (  <<5  10))  ( *  6  10);  >  ) 
(enemy  (  <(7~9>  (7  10))  ((6  9)  (7  10))  ((6  10))  )  D 
'corridor3) 

(putprop  'paths  '(  ((5  10)  '6  9)  (7  8))  ((5  9)  (6  3)  (7  9)) 

( (5  10)’  (6  10)  (7  10)  ) ) 

'corr idor3 ) 

(putprop  'general  area  '  (4  8)  (5  8)  (6  8)  (7  8)  (3  8) 

<4  9 >  (5  9)  (6  9)  (7  9)  (8  9) 

(4  10)  (5  10)  <6  10)  (7  10)  (8  1C)  > 

' corr idor3) 

(putprop  'center-point  '(6  9)  'corridor3> 

(putprop  'defend! points  '(  (friend  <  <<4  ID)  D5  ID)  ((6  ID) 
(enemy  (  ((7  ID)  ((611))  ((5  ID)  >  )  ) 

'corr idor 4 ) 

(putprop  'paths  '(  ((4  11)  '5  11)  (6  12)  (7  ID)  ( f  4  ID  <5  12) 
'corr idor4) 

(putprop  'general  area  '(  (4  ID  (5  ID  (6  ID  (7  ID  (3  11> 
(4.12)  (5  12)  (6  12)  (7  12)  (8  12)  ) 


)  ) 


(6  11)  (7  12))  * 


'corridor4 ) 

(putprop  'center-point  '(6  11)  'corridor4) 

;  for  units  that  must  backup  the  attack  or  defense  of  two  or  more  corridors 
;  support  areas  are  defined 

;  these  support  areas  represent  where  these  units 
;  should  locate  before  moving  into  one  of  the  supported  corridors 
; separate  support-areas  are  defined  for  the  friendly  and  enemy  side 
( putprop  'support-areas  '(((corridorl  corridors  ) 


(  (2  4)  (1 
< (corr idor 2 

3)  (1  4)  (1 
corridors ) 

5)  (2  3) 

(2  4) 

(2  5) 

<3  3)  <3  4) 

*  j 

5) 

(  (2  7)  (1 
(  ( corridorS 

6)  (1  7)  (1 
corr idor4 ) 

3)  (2  61 

f  2  7) 

(2  3) 

(3  6)  1 3  7' 

t  -» 
-/ 

3) 

(  (2  10)  (1  9)  <1  10)  (1  11)  (2  9  > 

(2  10)  (2  ID  (3  9)  (3  10)  (3  11)  )  > 
((corridorS  comdor3  corndor4) 

(  (2  8)  (2  9)  (3  8)  (3  9)  >  > 
((corridorl  corridor2  corridorS) 

(  (2  5)  (2  6)  (3  5)  (3  6)  >  ' 

) 
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' friend) 

(putprop  ' support.areas  7 ( ( (corridorl  corridor2> 

(  (11  5)  (10  4)  (10  5)  (10  6)  (11  4)  (11  5)  (11  6) 

(12  4)  (12  5)  (12  6)  )) 

((corridor2  corridors) 

(  (10  7)  (9  6)  (9  7)  (9  8)  (10  6)  (10  7)  (10  8) 

(11  6)  (11  7)  (11  8)  )) 

((corridor3  corridor4) 

(  (11  11)  (10  10)  (10  11)  (10  12)  (11  10)  <11  11)  (11  12) 

(12  10)  (12  11)  (12  12)  )) 

((corridorl  corridor2  corridor3) 

(  (10  5)  (10  6)  (11  5)  (11  6)  )) 

(<corridor2  corridors  eorridor4) 

(  (10  8)  (10  9)  (11  8)  (11  9)  )  ) 

) 

7enemv) 

;  once  the  terrain  board  is  specified  then  units  can  be  placed  on  the  boar 
;  to  defin  a  starting  position  this  is  done  below 
;  in  effect  the  following  xs  an  example  of  ar«  initial  set  up 
(setq  realboard  terrain.board) 

(putprop  'time  0  'realboard) 

(setq  friendly. units  nil) 

(setq  enemv.uni ts  nil) 

(setq  all. units  nil) 

;in  the  unit  defintions  below 

;  define. unit  sets  up  the  property  lists  that  define  each  unit 

;  put.unit. on. board  actual  puts  the  unit  on  the  realboard 

(def ine. unit  '1AD  'enemy  '1st  'armour  'division  12  9  8-5  4  '(8  G)  t) 

( put. unit. on. board  'realboard  '1AD  '(8  6)) 

( def ine. unit  '2AD  'enemy  '2nd  'armour  'division  12  9  3.5  4  ' <8  5>  t> 

(put. unit. on. board  'realboard  '2AB  '(8  5>> 

(def ine. unit  '3AB  'enemv  '3rd  'armour  'division  12  9  8.5  4  '*'3  7>  t> 

( put. unit.cn. board  'realboard  '3AD  ''8  7)) 

(def ine. unit  MAD  'enemy  Mth  'armour  'division  12  9  3.5  4  '(96)  t> 

( put. unit. on. board  'realboard  MAD  (9  6)) 

( def ine. unit  '1HD  'enemy  '1st  'infantry  'division  10  9  6  4  '(9  5>  t) 
(put.unit. on. board  'realboard  '1KB  '(9  5)) 

(def ine.unit  '2MD  'enemy  '2nd  'infantry  'division  10  9  6  4  ' < 10  7)  t > 

( put. unit. on. boar d  'realboard  '2MB  '(10  7)) 

(def ine. unit  '3MB  'enemy  '3rd  'infantry  'division  10  9  6  4  ''9  ?)  t) 

(put. unit.cn. board  'realboard  '3MB  '(9  7)) 

(def ine. unit  MHD  'enemy  '3rd  'infantry  'division  10  9  6  4  '<9  9)  t> 

< put. unit. or*. board  'realboard  MHD  '(9  9)) 

(def ine. unit  '5HD  'enemy  '3rd  'infantry  'division  10  9  6  4  "(7  1.)  t> 
(put.unit. on. board  'realboard  '5HD  '(7  ID) 

(def ine. unit  '6MD  'enemy  '3rd  'infantry  'division  10  9  6  4  '<8  3)  t> 

( put. unit. on. board  'realboard  'GHD  '(8  3)) 

(def ine. unit  '7MD  'enemy  '3rd  'infantry  'division  10  9  6  4  '<3  2)  t) 

( put. unit. on. board  'realboard  '7KB  '(3  2)) 

( def  ine. unit  'ICR  'friend  '1st  'cavalry  'regiment  5  5  7  4  '(«3  ■>)  t) 

( put. unit. on. board  'realboard  'ICR  '(6  6>> 

< def ins. unit  '1TB  'friend  '1st  'tar.l-  'division  10  9  7  4  '<36*  *  ) 
(put_unit.cn. board  'realboard  * 1TD  '*3  6>> 

(define. unit  '2TB  'friend  '2nd  'tank  'division  10  9  7  4  'M  10)  t) 

( put. unit. on. board  'realboard  '2TB  '<4  10) > 

(define  unit  '3TD  'friend  '3rd  'tank  'division  10  9  7  4  '-'3  41  t> 
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( put_uriit_or«_boar d  'realboard  '3TD  '<3  4>) 

(def ine_unit  '2ID  'friend  '2nd  'infantry  'division  3  10  7  4  '(4  7)  t) 

' put_unit_on_board  'realboard  'SIB  '(4  7>> 

( def ine_unit  '1ID  'friend  '1st  'infantry  'division  8  10  7  4  '(4  5)  t) 

< put_unit_on_board  'realboard  '1IB  '(4  5)) 

<define_unit  '3ID  'friend  '3rd  'infantry  'division  8  10  7  4  '(4  11)  t> 

*  put_unit_or«_board  'realboard  '3IB  '(4  ID) 

( def ine_unit  '4IB  'friend  '4th  'infantry  'division  8  10  7  4  '( 5  3)  t> 

( put_unit_on_board  'realboard  '4IB  '(5  3)) 

:  at  this  point  the  entire  board  has  been  defined 

;  the  following  is  a  list  of  top  level  goals 

;  if  you  understand  how  the  goal  defintions  work  you 

;  should  be  able  to  pick  up  the  aeaning  of  these  goals 

(setq  esgoall  ' (attack _corridors  (( (corridor  1  <7«o  6ad  lad  Sad)) 

(corridor3  (3ad  4ad  3ad  4ad)>> 

5)  >) 

■setq  esgoal2  '’defend  corridors  (< (corridors  (lad  2ad)>  *  corridor  4  (3ad>>' 

7)  >) 

(setq  egoall  (list  'andsia  (list  esgoall  esgoal2>>> 

(setq  esooal3  ''attack  corridors  (•' (corridors  (lad  Sad  3ao  4ad  lad  3ao  6ad>)> 

5)  >  ) 

(setq  esgoal4  '  (defend_corr  ldors  (( (corridor  1  (7«d)>  'corridors  (4*d  Sad))  (corndc 
7))) 

(setq  egoal2  (list  'andsia  (list  esgoa!3  esgoal4)>> 

(setq  esgoal5  * (attack_corridors  (((corridor!  (lad  Sad  4ad>> 

(corridor 3  (Sad  4ad  3ad>))  5))) 

(setq  esgoal6  '  (defeno_corndors  (((corridorl  (Gad)'  (corridor4  <3ad>>> 

7))) 

(setq  esgoal7  ' 'support_plan  (  C  (  ((corridorl  defend)  (corridors  attack))  <7ad) > 

(  ((corridors  attack)  tcorridor3  attack))  -lad)) 

(  ((corridors  attack)  (corridor4  defend))  (2ad))> 

2)  >) 

(setq  egoaiS  (list  'andsia  (list  esgoalS  esooalG  esgoal?) > > 

’ setq  esgoal8  ' (attack_corridors  (((corridorl  (Gad  7ao  Iso:} 

(corridor 2  (lad  Sad  3ad))) 

5) )) 

(setq  esgoa!9  '(defend  corridors  (((corridor!  (4ad  3ad)>  <corridor4  (Sad))) 

7))) 

(setq  esgoallO  ' (support.plan  (  (  (  ((corridorl  attack)  (corridors  attack))  (Sad  4* 
2))) 

(setq  egoal4  (list  'andsia  (list  esgoal8  esgoal?  esgoallO))) 

(setq  egoal  (list  'or  (list  egoaiS  egoal3)>> 

(setq  fgoall  ' (defend_corr idors  (((corridorl  (4id  3td>)  (corridor!  (lid  Sid  icr?  • 
(corridor?  (ltd  2td>)  (corridor^  (3id)))  7))' 

(setq  fsgoall  ' (defend_corridors  (((corridorl  (4id>*  (corridors  (lid  icr>) 

(corridors  (2td)>  (corridor4  (3id>?)  7)>> 

'setq  fsgoal2  ' < suppor t_plan  (  i  *  ((corridorl  defend)  (corridcrS  defend))  (3td>  > 

(  ((corridors  defend)  *corridor3  defend? )  '-ltd'  ' 

(  ((comdor3  defend)  (corndor4  defend))  (Sid)  >> 

2)  > ) 

(setq  fgoalS  (list  'andsia  tlist  fsgoall  fsgoalS))* 

(setq  fsgoal3 

'  (suoport_plari 

(  (  t  ( (cor - luor !  defend)  (corridors  defend)  'corridors  defend'*  -3td)  • 

c  ((corridors  defend?  (corridor  3  defend)  » corn  dor  4  defend) )  'ltd  Sxd>  >> 
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1 ) ' ) 

(seto  '903I3  (list  'andsim  (list  fsgoall  fsgoal3>)> 
(setq  i'g-'al  (list  'or  (list  fqoal2  fgoalS))) 


PROGRAM  3 

GOAL  DEFINITION  PARAMETERS 
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;  these  are  the  parameters  for  all  goal  definition 
;  at  present  procedures  used  in  a  goal  definition  can  use  no 
;  other  parameters  —  this  is  had  and  should  he  replaced  with 
;  macros  someday 
(defvar  gtmpgoal  nil) 

;  this  is  the  goal  name 
(defvar  gtmpargs  nil) 

;  all  arguements  of  the  goal  name  are  in  this  list 
(defvar  gtmphname  rm) 

;  this  specifies  the  board  name 
(defvar  gtmpside  nil) 

;  this  is  the  side  being  processed 
;  makegoal 

;  a  simple  routine  that  puts  specifed  lisp  code  on  property 
;  list  of  a  goal 
(defun  makegoal  (call) 

(putprop  'type  'specific  (car  call)) 

(putprop  'subgoal  nil  (car  call)) 

(putprop  'countergoal  'universe  (car  call)) 

(putprop  'feasible  t  (car  call)) 

(putprop  'succeeded^if  nil  (car  call)) 

(putprop  'failed^if  nil  (car  call)) 

(putprop  ' dor»t_ cont inue_  1  f  nil  (car  call)) 

;  the  above  putprops  set  default  values 
;  the  prog  below  replaces  default  values  with  values 
;  specified  in  goal  definition 
(prog  (gname  cur  1st) 

.(setq  gname  (car  call)  1st  (cddr  call)) 

(putprop  'args  (cadr  call)  gname) 
loop  1 

(setq  cur  (car  1st)  1st  (cdr  1st)) 

(and  cur  (putprop  (car  cur)  (cadr  cur)  gname)) 

(and  1st  (go  loopl)) 

( return  gname) ) ) 
y  process^goal 

;  retrieves  specific  property  and  evals  it  after  setting  up 
;  necessary  globals 

;  this  is  done  by  setting  up  the  four  goal  definition  arguements 
;  and  processing  type_process 

(defun  process^goal  (bname  goal  side  ty pe_pr ocess > 

(setq  gtmpgoal  (car  goal)  gtmpargs  (cadr  goal) 
gtmpbname  bname  gtmpride  side) 

(eval  (get  type_process  (car  goal))) 

) 

::  Note  this  approach  to  defining  goals  should  be  replaced  with 
;  a  soohi s ticated  goal  description  language 

;  an  important  question  is  however  how  much  such  a  language  should  be* 
;  domain  dependent 
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in  finalgame.l 

the  goal  definition  which  is  a  frame- like  representation 
has  the  following  structure 
( makegoal 

'< goal name  (arguements) 

(type  kkkkkkkk) 

{  S U b g O 3 1  ■k'k'kk'k'kk-k  ) 

(counter goal  kkkkk*kkk) 

(feasible^if  kkkkkkkkkk  ) 

( succeeded^if  kkkk-kkkk) 

(fa iled_if~*AAAAA***> 

< dont^cont inue_i f  AAkkkkkkk) 

these  elements  of  the  goal  structure  can  be  interpreted  as  follows 
goal name  -  is  the  name  of  the  goal  --  it  must  be  a  unique  atom 
arguements  -  is  a  list  of  the  arguements  used  bv  the  goal 

when  a  goal  definition  is  being  processed  these  arguements  are 
contained  in  the  global  variable  gtmpargi* 
type  -  allows  characterisation  of  the  goal 

not  used  now  but  will  be  useful  m  future  versions 
default  is  specific 

subgoal  -  the  eval  of  the  contents  of  the  subgoal  slot  must 
evaluate  to  a  list  of  subgoals  --  default  is  ml 
countergoal  -  the  eval  of  the  contents  of  the  countergoal  slot  must 
eval  to  s  list  of  acceptable  counter  goals 
this  slot  is  not  used  for  the  wargame  because  but 
is  very  useful  for  sinQle  ^ove-coi-nterniove  games  such 
as  chess  go  othello  —  default  is  'universe 
feasible  -  a  procedure  that  should  eval  to  t  or  ml 

to  indicate  wnether  it  is  feasible  to  pursue  the 
goal  m  the  present  situation  --  default  is  t 
succeeded_if  -  a  procedure  that  shot.: Id  eval  to  t  or  m  1 

to  indicate  whether  the  goal  has  been  achieved 
in  the  present  situation  --  default  is  ml 
f'ailed_if  -  a  procedure  that  should  eval  to  t  or  ml 
to  indicate  whether  the  goal  has  faile**l 
in  the  present  situation  --  default  is  ml 
dont_coritinue_i f  -  a  procedure  that  should  eval  to  t  or  m3 

to  indicate  whether  the  goal  has  become  irrelevant 

but  cannot  be  marked  as  succeeded  or  failed  —  default  is  m 1 

GENERIC  GOALS 

the  following  are  generic  goals  that  can  be  used  in  anv  domain 
they  represent  knowledge  about  goals  th3t  is  independent  of  knowledge 
about  a  domain 
.andsim  generic 

subgoal  is  andsim  of  suogoal  of  the  goals  in  its  arguements 
f ailed^if  any  one  sub*oal  is  a  failure 
succeeded_if  all  of  its  subgoals  succeed 

dont_cGritinue_if  not  3ll  but  at  least  one  subgoal  succeeds 
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( make goal 

' ( ands im  <  goals  > 

(type  generic) 

; subgoal  is  a  list  that  equals  all  possible  combinations  of  a  1.1 
; subgoals  of  the  goals  m  the  andsim  arguement 
( subgoal 

(prog  (tmpl  tmp2  tmpbname  tmpside) 

( setq  tmpl  gtmpargs  tmpbname  gtmpbname  tmpside  gtmpside) 
loopl 

(setq  tmp2  (cons  ( process_goal  tmpbname  (car  tmpl)  tmpside  'subgc  /  +mo2) ) 

(and  (setq  tmpl  (cdr  tmpl))  (go  loopl)) 

(setq  tmp2  (remove  ' no_l onger_relevant  tmp2) ) 

(and  (null  tmp2>  (return  '  no^longer^ rel evant ) ) 

;  loopl  gets  all  subgoals  for  each  goal 
'.setq  tmpl  ( all _combi nations  tmo2)  tmp2  nil) 

;  traol  is  now  list  of  all  combinations  of  subqo 
i  o  o  p  2 

(setq  tmp2  (cons  (list  'andsim  (car  tmoi>)  tmo2)  ' 

(and  (setq  tmpl  (cdr  tmpl))  (go  loop2>) 

:  now  each  list  of  subgoals  is  andsim  subgoal 
(return  tmp2) 

;  list  of  andsxms  is  now  returned 
)  ) 

; if  all  of  the  component  goals  of  the  andsim  succeed  then  the  andsim  has  succee 
( succeeded_if 

(prog  (tmpl  tmpbname  tmpside  rslt) 

(setq  tmpl  gtmpargs  tmpbname  gtmpbname  tmpside  gtmpside) 

1  oopl 

(setq  rslt  < process_goal  tmpbname  (car  tmpl)  tmpside  'succeeded _ if ) ) 

(and  (null  rslt)  (return  ml)) 

(and  (setq  tmpl  (cdr  tmpl))  (go  loopl)) 

(return  (list  'succeeded  tmpside)))) 

; if  just  one  subgoal  of  the  component  goals  has  failed  then  the  andsim  nas  fail 
(f ailed_if 

(prog  (tmpl  tmpbname  tmpside  rslt) 

(seta  tmpl  gtmpargs  tmpbname  gtmpbname  tmpside  gtmpside) 
loopl 

(setq  rslt  ( process^goal  tmpbname  (car  tmpl)  tmpside  'failed. if)  ) 

(and  rslt  (return  (list  'failed  tmpside  (car  tmpl)  rslt>>> 

(and  (setq  tmpl  (cdr  tmpl))  (go  loopl)))) 

; if  any  of  the  component  subgoals  of  the  andsim  should  not  be  continued  then 
;dont  continue  the  andsim 
( dont_continue_if 

(prog  (tmpl  tmpbname  tmpside  rslt) 

(setq  tmpl  gtmpargs  tmpbname  gtmpbname  tmpside  gtmpside; 
loopl 

(setq  rslt  < process_goal  tmpbname  (car  tmpl)  tmpside  'dont  ..continue  if)) 

' ( and  (null  rslt) 

(setq  rslt  ( process _goal  tmpDname  (car  tmol)  tmpside  ' succeeded _if )> > 

(and  rslt  (return  'list  'dont^cont  mue^if  tmoside  fcar  *mpl>  rslt))) 

(and  (setq  tmpl  (cdr  tmpl > >  (go  loopl));) 

) 

) 

:  orsim  generic 

;  pursues  multiple  simultaneous  goals  and  fails  if  all  goals  fait 
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ucceeded.if  any  one  subgo.al  is  a  success 
ailedMif  all  of  its  subgoals  failed 
;  dont_continue_if  not  all  but  at  least  one  subgoal  failn 
( makegoal 

' ( orsim  ( goals ) 

< type  generic) 

; subgoal  evals  to  a  list  of  3ll  combinations  of  all  subgoals 
:of  the  component  goals  of  goals 
( subgoal 

(prog  (tmpl  tmp2  tmpbname  tmpside) 

(setq  tmpl  gtmpargs  tmpbname  gtmpbname  tmpside  gtmpside) 
loopl 

(setq  tmp2  (cons  ( process, goal  tmpbname  (car  tmpl)  tmpside  'subgoal/  tmp2) ) 
/ and  (setq  tmpl  (cdr  tmpl))  (go  loopl)) 

(seta  tmp2  (remove  ' no_longer _relevant  tmp2)  ) 

;  loopl  gets  ail  subgoals  for  each  goal 

(setq  tmpl  ( al 1 _combinat ions  tmp2)  tmp2  nil) 

;  tmpl  is  now  list  of  all  combinations  of  subgoals 

loop2 

(setq  tmp2  (cons  (list  ' or sim  (car  tmpl))  tmp2)  ) 

(and  (setq  tmpl  (cdr  tmpl))  (go  loop2)) 

;  now  each  list  of  subgoals  is  andsim  sub goal 
(return  tmp2) 

;  list  of  orsims  is  now  returned 
) ) 

: succeeded,if  any  of  the  component  goals  have  succeeded 
<succeeded_if 

(prog  (tmpl  tmobriame  tmpside  rslt) 

(setq  tmpl  gtmpargs  tmobname  gtmpbname  tmpside  gtmps..de> 
loopl 

(setq  rslt  k process, goal  tmpbname  (car  tmol)  tmpside  ' succeeded _if )  / 

(and  rsit  (return  (list  ''succeeded  tmpside  (car  tmpl)  rslt))) 

(and  (setq  tmpl  (cdr  tmpl))  (go  loopl)))) 

Jfailed  if  all  of  the  component  goals  have  faileo 
(failed, if 

(prog  (tmpl  tmpbname  tmpside  rslt) 

(setq  tmpl  gtmpargs  tmpbname  gtmpbname  tmpside  gtmpside) 
loopl 

(setq  rslt  ( process, goal  tmpbname  (car  tmpl)  tmpside  failed, if) > 

(and  (equal  rslt  t)  (return  (list  'failed  tmpside  (car  tmpl)))) 

(and  rslt  (return  rslt)) 

(and  (setq  tmpl  (cdr  tmpl))  (90  loopl)) 

(return  nil))  ) 

;dont_eorr,inue,if  any  of  the  component  suDgoals  should  not  be  continued 
;or  if  any  of  the  component  goals  have  failed 
( dont  ,cor*t  1  nue  _  1  f 

( proq  (tmpl  tmpbname  tmpside  rslt) 

(setq  tmpl  gtmoargs  tmpbname  gtmobname  tmpside  gtmpside) 
loopl 

(setq  rslt  ( process, goal  tmpbname  (car  tmpl)  tmpside  ' dont ..continue, 1 f )  > 

7  f  and  ( riui  1  rslt) 

(setq  rslt  ( proeess_goal  tmpbname  (car  tmol)  tmoside  ' f si led_if > )  ) 

(and  rslt  (return  (list  dont ^continue  .if  tmoside  (car  tmol*  rslt))' 
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<  and  (setq  tmpl  (cdr  tmpl))  (go  loopl)))) 

) 

) 

;  or 

;  logical  or  of  goals 
( mak egoal 

' < or  (goals  ) 

(type  generic) 

(subgoal  gtmpargs) 

) 

> 

5  DOMAIN  SPECIFIC  GOALS 

;  the  following  goals  are  unique  to  this  wargame* 

;  NOTE  that  these  goals  do  not  make  use  of  bcardval  routines 
;  (although  some  supporting  utilities  do)  consequently 
;  if  there  is  an  occassional  board  conflict  with  two  units  on 
;  the  S3me  position  (can  only  occur  by  an  error  in  backup) 

;  tnen  planner  will  still  continue  without  error 
;  def end_corr ldor  s 

;  goal  that  speicifies  corridors  to  be  defended  and  the  units 
;  to  defend  with 

<  makegoal 

'  ( def  end.cor r  idors  ( list  _of _c_arid_unit_l  ist  t»v_time  *> 

( type  specific ) 

( subgoal 

(prog  (tmpl  tmp2) 

(setq  tmpl  (first  gtmpargs)) 
loopl 

< and  tmpl 

(setq  tmp2  (cons  (list  'def end_l_corridor 
(list  (caar  tmpl)  (cadar  tmpl) 

(second  gtmpargs)))  tmp2))) 

(and  (setq  tmpl  (cdr  tmpl))  (go  loopl)) 

; above  loop  decomooses  arguements  into  comoonent  goals 
(cond  fi>  (length  tmp2)  7)  (return  (list  (list  'andsim  tmp2)))> 
((=  (length  tmp2)  1)  (return  tmp2)>)> 

; if  more  than  one  subgoal  make  andsim  subgoal 

> 

) 

<  mak  egoal 

' < def end_l_cor r idor  (corridor  1 ist_of jjrats  bv_time) 

(type  specific) 

(subgoal 

(prog  (tmpl  trop2  tmo3  tmp4  tmp5) 

(setq  tmpl  (get  def  end-points  gtmpbname  -.car  Qtmpargs)  gtmpside) 
tmp3  (second  gtmpargs) 
tmp4  (union 
( second  gtmpargs ) 

( urats.ift.area  gtmpbname 
(get  'general-area  (first  gtmpargs)) 
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gtmpside ) ) > 

;tmpl  is  list  of  locations  to  defend 

; tmp3  is  list  of  units  available 

;tmp4  is  tmp3  plus  list  of  units  already  there 

(and  <>  (length  tmpl)  (length  tmp4)>  (return  nil)) 

;if  not  enough  units  assigned  then  failure 
<  setq  tmp5  tmp3> 

;tmp5  is  initially  set  to  list  of  all  units 
loopO 

(and  (member  ( unites tatus  gtmpbname  (car  tmp5)  'location) 
tmpl ) 

t  (setq  tmp2 
(cons 
(list 

' def end_location 
(list  (car  tmp5 ) 

(unit.status  gtmpbname  (car  tmpS)  'location))) 
tmp2>"> 

(setq  tmp3  (remove  (caadar  tmp2)  tmp3))) 

(and  (setq  tmpS  (cdr  tmp5)>  (go  loopO)) 

; loopO  checks  all  units  in  list. of  ..units  to  determine  if 
;  unit  is  already  or*  a  def  end-point  --  if  yes  then  it  stays 
;and  defends  th3t  location 
1  oopl 

(and  tmpl  tMp3 
(setq  tmo2 

(cons  (list  'def end^loc ation 

(list  ( closest^unit  gtmpbname  (car  tmpl)  tmp3) 

(car  tmpl )  ) ) 
tmp2 ) ) ) 

(setq  tmpl  (cdr  tmol)  tmp3  (remove  (caadar  tmp2)  tfito3;  • 

(and  tmpl  (go  IoodI') 

( and  tmp3 
-  (setq  tmpl 

< get^def end-points  gtmpbname  (car  gtmpargs) 
gtmpside))  (go  ioopl)) 

Jloopl  oGes  through  all  the  units  not  already  on  a  defend  point 
;and  assigns  each  one  to  a  specific 
; location  that  it  should  move  toward  and  defend 
(return  (cond  ((,■  (length  tmp2)  1)  (list  (list  'ar.dsim  tmp2)>> 

((=  (length  tmp2)  1)  tmp2))> 

)  ) 

;failed_if  cannot  find  defend  points  This  only  happens  if 
;enemy  has  already  broken  through 
(f ailed^if 
(orog  (tmpl; 

(seta  tmpl  ( get_def end. points  gtmpbname  (first  gtmpargs)  gtmoside;  ) 
(cond  ((null  tmpl)  i  return  t)> 

<t  (return  nil))) 

)  ) 

;if  get  past  time  by-time  without  failing  then  nas  succeeded 
( c.ucceeced_if  <  *  time  gtmobnamei  (third  gtmpargs)  >> 
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) 

;  def end_location 

;  this  goal  is  to  move  to  a  specified  location  and  the  defend  it 
( makegoal 

' ( def end_lacat ion  (unitname  location; 

(type  specific) 

<  subgoal 

( cond 

((equal  <unit_status  gtmpbname  (first  gtmpargs)  'location)  *  second  gtm 
(list  (list  'send  (list  (list  (car  gtmpargs)  ' (defend, m^place) >)>) ) 
<t  (list  (list  'send  (list 
'list  (car  gtmpargs) 

(cons  'move  (get^path  glmobname  (first  gtmoargs) 

(second  gtmpargs)  6  t)  )>?))))) 

: if  at  location  stay  there  else  move  to  location 

< dont^contmue.if 
(prog  (tmpl) 

(setq  tapl  (boardval  (eval  gtmpbname)  (second  gtmoargs))) 

(and  tmpl  (setc  tmpl  ( umt__st  atus  gtmpbname  tmpl  'side))' 

(cond  ((equal  tmol  ( opposite^s ide  gtwDsxde)) 

(return  t ) ) 

(t  (return  nil)))  ) 

) 

;dont_continue_if  other  side  occupies  location 

> 

) 

;  attack^corndor  s 

:  assigns  a  set  of  units  to  a  set  of  corridors  for  an  attack 
( makegoal 

' < attack _c or r i dor s  < 1 xst_of _c  _  and  _umt_  list  bv_t ime  * 

(type  specific) 

<  subgoal 

(prog  (tmpl  tmp2) 

(setq  tmpl  (first  gtmpargs)) 
loopl 

(and  tmpl 

(seto  tmp2  (cons  (list  ' attack _l_corr idor 
(list  (ca ar  tmpl)  (cadar  tmpl) 

(second  gtmpargs)))  tmp2))> 

(and  < setq  tmpl  (cdr  tmol))  (go  loopl)) 

(return  (list  (list  'orsim  tmp2))))> 


) 

(makegoal 

' <  attack  _l_cor r 1 dor  < cor  r idor  I ist  of  units  bv_time  ) 
(type  specific % 

( subgoal 

(prog  (tmpl  t»p2  tmp3  tmp4’f 

(seta  tmpl  ( paths  _ir,_  cor  r  idor  gtmpbname 
(first  gtmpargs)  gtmpside) 
tmp2  Second  gtmpargs)) 
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loopl 

(setq  tmp3  (hest_unit_f or  gtmpbname  (car  tmpl)  tmp2>  ) 

;tmp3  is  the  preferred  unit  to  90  down  path 
(setq  tmp4  (cons  (list  ' attack_down_pat h 
(list  tmp3  (car  tmpl)  (first  gtmpargs)))  tmp4)) 

;add  9oal  of  attack  down  path  car  tft.pl  with  unit  tmp3 
(<setq  tmpl  (reverse  (cons  (car  tmp:  )  (reverse  (cdr  tmpl))))) 

:move  path  to  end  of  path  list 
(<setq  tmp2  (remove  tmp3  tmp2)) 

;remove  unit  tmp3  from  list  of  units  twp2 
(and  tmp2  (90  loopl)) 

;as  long  as  there  are  units  left  assign  them 
(cond  ((>  (length  tmp4)  1) 

(setq  tmp4  (list  (list  'andsim  tmp4>))> 

((=  (length  tmo4)  1) 

(setq  tmp4  tmp4))> 

m,  subgoal  is  andsim  of  several  attacks  or  just  one  attack  with  no  andsim 
(return  t»p4))) 

( succeeded,.!  f 
(prog  (tmpl) 

(seta  tmpl  (get_def end-points  gtmpbname  (first  gtmpargs)  ' ooposite_side  gtmps 
( cond  ((null  tmpl)  (return  t)) 

(t  (return  nil) ) ) 

)  > 

(failed_if  <>  (get  'time  gtmpbname)  (third  gtmpargs))) 

)  ) 

;  attack_down_path 

;  identifies  specific  path  of  attack  through  corridor 
( makegoal 

' ( attack_down_path  (unit  path  corridor) 

(type  specific) 

( supgoal 

( prog  ( tmpl  t»p2 ) 

(setq  tmpl  ( f ir st_def end. unit  gtmpbname  (third  gtmpargs) 

<opposite_side  gtmpside))) 

: identify  first  unit  defending  corridor 

(and  <C3n_attack_uriit  gtmpbname  (first  gtmpargs)  tmpl) 

(return  (list  (list  'send 

(list  (list  (first  gtmpargs) 

(list  ' attack  tmpl))))))) 

; attack  any  units  in  the  way 

(and  (setq  tap2  (member  ( uni t_status  gtmpbname  (first  gtmoargs)  'location) 

( second  gtmpargs ) ) ) 

(return  (list  (list  'send  (list  (list  (first  gtmpargs; 

(cons  'move  (cdr  tmp2)>)>>>)> 

;if  can  not  attack  and  member  of  path  then  march  down  oath  if  can 
(return  (list 

(list  'send  (list  (list  (first  gtmpargs) 

(cons  'move  (append 

(get^path  gtmpbname  (first  gtmpargs; 

(car  (second  gtmoargs)) 

6  t) 

'cdr  (second  gtmpargs) >))))>) > 

;if  nothing  else  move  unit  toward  beginning  of  path  and  march 
; down  path 
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) ) 

( succeeded_i f 

(equal  (unit_$tatus  gtmpbname  (first  gtmpargs)  ' location) 
(car  (reverse  (second  gtmpargs )>)>  ) 

;succeeded_if  wade  it  to  the  other  end 
> ) 

;  support  plan 

;  assigns  units  to  support  positions  until  corridor 
;  conflict  is  near  resolution  then  supports 
<  makegoal 

' ( support^plan  < 1 ist^of _corr idors_and_units  tempo) 

(type  specific) 

( subgoal 

(prog  (tmpl  tmp2> 

(setq  tmpl  (first  gtrupargs)) 
loopl 

*'  setq  tmp2 
'  cons 

(list  ' sup por t _cor r ldor s 
(list  (first  (first  tmpl)) 

(second  (first  t«pl)> 

( +  (second  gtmoargs)  (get  "time  gtwpbname ) } ) >  twp2> > 
(and  (setq  tmpl  (cdr  tmpl)}  go  loopl)) 

(return  (list  (list  'andsim  t»p2)>) 


) 

support  corridors 

specific  suoport  corridor  goal 

st  present  makes  use  cf  a  global  variable  called  suopor t,ed_cor r  idor  that 
set  to  nil  on  newturr.  sorry  bad  form 
( makegoal 

'  ( supoort^cor r idors  <  1  ist^corr  idors_ati'  def  units  waxt_unt i  l_t  ime  > 

(type  specific) 

( subgoal 

(prog  (tmpl  twp2  tmp3  tmp4  subgoals  in_eorr idor > 

(setq  tmpl  (first  gtmpargs)  tmp2  (second  gtmpargs)  t»p3  t»p2  twp4  tmpl 
Jtmpl  and  tmp4  list  of  corridors 
;tmp2  and  tmp3  list  of  units 
loopO 

( cond  ((and  (null  (member  (unit_status  gtwDbr.awe 
(first  tmp3>  'location) 

( support_area  tmpl  gtmpside))) 

;if  unit  not  in  support  area 

fae-nber  (car  tmp3)  ( scti  ve^units  gtmpside)  = 

;  unit  x s  alive 
i ecu a 1 .intersect 

<unit_status  gtmpbname 
(first  twp3)  ' retreated i recti on ) 

( supoor t_area  t*ol  gtmoside>>> 

:  unit  previously  was  in  support  are? 

( <*?etq  m_corr  idor 

( wnicn_corr idor?  gtmpbname  (first  gtmpargs) 
if irst  t»p3> ) > 

:ther.  identify  whiui  corridor  it  is  r.c*u  supportinn 
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(and  (equal  (second  in_corridor)  'defend) 

(setq  subgoals 

(cons  (list  'def end.l.corr idor 
(list  (first  in.corr idor ) 

(list  (first  t*p3>) 

100) ) 

subgoals) ) ) 

;and  defend  that  corridor 

(and  (equal  (second  ir»_corr idor  >  'att-ck) 

(setq  subgoals 

(cons  (list  'attack_l_corr idor 
(list  (first  in.corr idor ) 

(list  (first  tmp3)> 

100)  > 

subgoals) ) > 

tor  attack  that  corridor 

(setq  t*p2  (reiove  (car  tmp3)  t»p2)) 

;remove  the  unit  fro*  list  of  units  to  consider  for  new  assignments 
)  ) 

(and  (setq  tmp3  (edr  tmp3>)  (30  loopO) > 

;  subgoals  now  has  all  previous  subgoals  included 
;tmp2  is  now  a  list  of  ail  other  units  to  assign 
;  tmpl  is  still  list  of  corridors 
(and  (null  t*p2>  (go  loop2)  ) 

;if  no  supporting  units  remain  then  skip  over  next  Xoopl 
loopl 

(cond  ((and  (equal  (second  (first  tmol>>  'defend) 

(null  (=  (get  'time  gtmobname)  (get  'time  'reaiboard) > > 

(null  (member  (list  (first  ‘first  tmpl))  gtmoside) 
supported.corr idorc ; > 

(need.help  gtmpbname  (first  tmpl)  gtmpside  3) > 

: check  if  defense  of  corridor  ir*  car  tmol  needs  nelp 
(and  tmp2 
(setq  subgoals 
(cons 

(list  ' defend. l_c or r idor 

(list  (first  -first  tmpl)) 

( list  (first  tm  d2 •  ) 

100) ) 

subgoals  > ) ) 
jsend  help 

( setq  supported^ccr r idor s 
(cons  (list  (first  (first  impl)>  gtmpside) 
supported. corridors) > 

Jrecord  fact  that  help  is  sent 
(setq  t*p4  (remove  (car  tmpl)  tmo4>  t»o2  <cdr 
Jremove  corridor  frc&  list  of  cornodrs 
t  ( and  (equal  (second  (first  tt*pl>)  'attach  1 
(null  t  =  (get  'time  gimobr.  .me)  ( 'time  'real  board  *  > ) 

(null  (member  (list  'first  -first  tmpl)>  gtupsid*- 
suppor ted.ccr  r  idors)  > 

(need. help  gtmpbname  -first  tmpl)  gtmpside  3  * > 

:  che ck  if  attack  ;r.  car  tmpl  should  c»e  supported 
<  and  tmp2 
(setq  subgoals 
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(cons 

(list  ' 3ttack_l_corridor 

(list  (first  (first  Upi)) 

(list  (first  t»p2> } 

100)) 

subgoals ) ) ) 

:send  support  to  attack 
<  setq  $upported_corridors 
(cons  (list  (first  (first  iapl>)  gtepside) 
suppor ted_corr idors ) > 

jrecGrd  fact  that  corridor  is  bexr«^  supported 
(setq  t»p4  (reaove  (car  taoi)  t*p4)  t»p2  (cdr  lap2> ) > 

; rewove  corridor  fro»  list  of  corridors  to  he  cheered 
) 

(and  (setq  two!  -'cdr  t«pl>>  (a o  loopi;> 

;get  r«e*t  corridor 

rassign  a  unit  to  defense  or  attack 
; never  nore  than  one  unit  one  for  a  corridor 

loop2 

(and  t«p2 
(setq  subgoals 
(cons 

(list  '  wove_to_support_pc*s 
(list  (first  gtapargs) 

(first  twp2>  >  > 
subgoals) > ) 

;all  regaining  units  should  «ove  to  suoport  corners 
(  and  *  setq  top2  (cdr  t^p2:  >  (go  loop2M 
;send  other  units  to  support  waiting  area 

(ccnd  ((>  (length  suoqcals)  1>  (return  ?  list  *iist  sn-is  i*  sut-goals)  >  >  J 
M  =  (length  subgoals)  1;  'return  subgoais>  > 

<  t  i return  nil >  >  > 

\ 

) 

(dont^contmue^if  'get  'tiae  gt»o Dr«a*e*  (third  gtup  ar  g  £  / 

> 

> 

i 

:  this  is  old  version  of  support  corridors 
;  support  corridors 
:  specific  support  corridor  goal 

:  at  present  wakes  use  of  a  lobai  variable  called  suopor ted_corr ldor  that  is 
:  set  to  nil  on  newt urn  iorrv  bad  forw 
' (wakegoal 

*  < support^corr ldors  <list_roi r  iors_atldef  units  wai t_ynti I :a»e  * 

( type  soecif ic) 

( sub goal 

(prog  *tmpl  t*p2  t*a3  iap4- 

(seto  twpl  (first  gt^oargsx  'second  gtwpargs#  tsap3  t«c*2  tsp4  twpl  > 

;twpl  and  t»p4  list  of  corrido;  . 

; tkp2  and  t*p3  list  of  units 
loopO 

(ar,d  (null  (wewber  (unit^status  gc'ttr.awe  'first  t=*.p2?  location* 
(support, area  twpl  gtwpside))) 

?  equal^mter  sect  (unit^status  gtwpb.a^s  *  first  t»p2.  retreat,  direction  » 
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( support^area  tmpl  gtmpside)) 

(setq  tmp2  (remove  (car  tmp3>  tmp2))> 

(and  (setq  tmp3  (cdr  tmp3))  (30  loopO)  ) 

{remove  any  units  not  waiting  in  support  area  but  previously 

;have  been  in  support  area 

Jtmp2  is  list  of  remaining  units 

(and  (null  tmp2)  (return  'no^longer^relevant) ) 

;if  no  supporting  units  remain  then  goal  is  irrelevant 

locpl 

(cond  ((and  (equal  (second  (first  tmp 1 ) )  'defend) 

(null  <9©t  'time  gtmpbname)  (get  'time  ' real  boar d )) ) 

(null  (member  (list  (first  (first  tntpl))  gtmpside) 
supported^corridors) ) 

(need_help  gtmpbname  (first  tmpl)  gtmpside  3)) 

; check  if  defense  of  corridor  in  car  tmpl  needs  help 
(and  t  mp2 
(setq  tmp3 
( cons 

(list  ' def end_l_corr idor 

(list  (first  (first  tmpl)) 

( list  (first  tmp2>  ) 

100)  ) 
t  mp3)  > ) 

{send  help 

( setq  supported^corr idor  & 

(cons  (list  (first  (first  tmpl))  gtmpside) 
supporteu^corridor s)  ) 

{record  fact  that  help  xs  sent 

(setq  tmp4  (remove  (car  tmpl)  tmp4)  tmp2  (cdr  tmp2)>) 

{remove  corrido.  from  list  of  corriodrs 
((and  'equal  (second  (first  tmpl))  'attack) 

(null  ( =  (get  'time  gtmpbname)  (get  'time  ' r eal board )  ) ) 

(null  (mem^r  (list  (first  (first  tmpl))  gtmpside) 
suppui ted_corr idors ) > 

'  (need. help  gtmpbname  (first  tmpl)  gtmpside  3)) 

{check  if  attack  m  car  tmpl  should  be  supported 
(and  tmp2! 

'seto  tmp3 
(cons 

4  list  ' attaek_l_corridor 

(List  (first  (first  tmpl)) 

(list  (first  tmp2)  ) 

}  00)  ) 
tmp3 )  )  ) 

{send  support  to  attack 
(setq  suppurted_corr i dor s 
(cons  (list  (first  (first  tmpl))  gtmpside) 
sup  port  «?d_corr  idor  s )  > 

;r'3c..rd  fact  that  corridor  is  being  supported 
(setq  tmp4  (remove  (car  tmpl)  tmp4)  tmp2  (cdr  tmp2>)> 

{remove  corrid cr  from  list  of  corridors  to  be  checked 

) 

(and  (setq  tmpl  (cdr  tmpl))  (go  loopl)) 
fqet  next  "orndor 

{assign  a  unit  tc  defense  or  attack 
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; never  more  than  one  unit  one  for  3  corridor 

loop2 

(and  tmp2 
(setq  tmp3 
(cans 

(list  /move_to_support-.pos 
(list  (first  gtmpargs) 

(first  tmp2) ) ) 
tmp3 ) > ) 

jail  remaining  units  should  move  to  support  corridors 
(and  (setq  tmp2  (cdr  tmp2))  (go  loop2)) 

;send  other  units  to  support  waiting  area 

(corid  (1/  (length  tmp3)  1)  (return  (list  (list  /andsim  tmp3))>) 

((=  (length  tmp3)  1)  (return  tmp3> > 

( t  ( return  nil))) 

> 

) 

( dont ..continue  Jf  (.'•*=  (get  'time  gtmpbname)  (tnird  gtmpargs)) 

) 

) 

) 

;  move_to,suppor t 

;  sends  unit  to  position  where  it  can  reinforce  any  of  the 
;  corridors  it  is  supposed  to  support 
( makegoal 

/(move-to_support_pos  (list^of^eorridors^&^goals  unit  ) 

(type  specific) 

( subgoa J 

(prog  (tmpl  tmp2) 

(setq  tmol  ( suppor t_area  (first  gtmpargs)  gtmpsade)) 

(cond  ((member  ( uni t_status  otmpbname  (second  gtmpargs)  'location) 
tmpl ) 

(return  (list  (list  'send  (list  (list  (second  gtmpargs;  '(no  order))))))) 
<t 

(setq  tmp2  (get  path  qtmobnaroe  (second  qtmpargs) 

( car  tmpl )  6  t ) ) 

(return 
(list 
(list  'send 
(list 

(list  (second  gtmpargs) 

(cons  'move  tmp2))>)>)) 

) 

) 

> 

) 

) 

;  send  specif  a  a 

;  uses  jnction  send, order  to  send  orders  for  each  una  t 
( makegoal 

(send  (orders) 


(type  specific) 
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<  subgoal 

(list  (list  'send  gtmpargs))) 

<  action 

( prog  ( tmpl ) 

(setq  tmpl  gtmpargs) 
loopl 

(send_order  (first  (car  tmpl))  (cadr  (car  tmpl))) 

(and  (setq  tmpl  (cdr  tmpl))  (go  loopl)) 

(return  nil ) >  > 

)  ) 

;  SOME  DOMAIN  UTILITIES 

;  TEMPORARILY  HERE  FOR  DEBUG ING  PURPOSES 
( defun  all .combinations  <list_ of -lists) 

(prog  (tmpl  tmp2  tmp3  tmp4) 

(setq  tmpl  list_of_lists  tmp2  (first  tmpl)) 
loopl 

(setq  tmp3  (cons  (list  (first  tmp2>)  tmp3) ) 

(and  (setq  tmp2  (cdr  t m p 2 ) )  (go  loopl)) 

;this  loop  sets  up  initial  list 
(setq  tmpl  (cdr  tmpl)  tmpl  (car  tmpl)) 

(and  (null  tmpl)  (return  tmp3)  ) 

;  continue  to  nest  loop  only  it  more  than  one  list. of. 1 ists 
loop2 

(setq  tmp4  (cons  (cons  (car  tmp2)  (car  tmp3))  tmp4)  ) 

(and  (setq  tmp2  (cdr  tmp2))  (go  loop2)) 

(setq  tmp2  (car  tmpl)) 

(and  (setq  tmo3  .cdr  tmp3)>  (go  loop2)) 

(setq  tmpl  (cdr  tmpl)  tmp2  (car  tmol )  tmp3  tmp4  tmp4  nil) 

(and  tmpl  (go  loop2)) 

;  this  35  main  loop  will  set  tmp3  to  list  of  lists  that  reflects 
;  ail  possible  combinations  of  the  initial  lists  in  1 i st.of .1 i sts 
(return  tmp3) 

) 

) 

(uexu"'  ge t.def end-points  (bname  corridor  side) 

(prog  ‘tmpl  tmp2  tmp3  tmp4) 

(setq  vrapl  (get  'defend. points  corridor)) 

;gets  list  of  friend  and  enemy  defend  points 
(cond  ((equal  side  'friend) 

(setq  tmpl  (cadr  (first  tmpl)))) 

((equal  side  'enemy) 

(setq  tmpl  (cadr  (second  tmpl))))) 

; loopl  goes  through  each  set  of  defend  points  and 
; looks  for  enemy 

;last  defend  points  before  enemy  is  set  up  3s 
{defend  points  return 
(setq  tmp2  (car  tmplM 
loopl 

(and  (setq  tmo3  (boardval  (eval  bname)  (car  tmo2))> 

(equal  ( unit. status  bname  tmp3  'side) 

< opposite_side  side)) 

(cond  ((>  (length  tmp4)  1) 

(return  ( r eor der _by_str ength  bname  tmp4  side))) 

(t  (return  tmp4>))) 

;if  multiple  defend  points  then  order  them  weakest  firsl 
(and  (setq  tmp2  (cdr  tmp2)>  (go  loopl)) 
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;  if  no  enemy  units  in  defend. line  tmp2  get  next  defend  line 
(setq  tmp4  (car  tmpl)  tmpl  (cdr  tmpl)  tmp2  (car  tmpl) ) 

;tmp4  is  set  to  last  defend. line 
(and  tmpl  (go  loopl)) 

Jgo  check  next  defend  line 
(and  (>  (length  tmp4)  1) 

(setq  tmp4  ( reorder _by_strength  bname  tmp4  side))) 

(return  tmp4) 

;if  no  enemy  found  then  return  farthers  defend  point 
) 

) 

;  reorder .by. strength 

;  function  will  return  a  set  of  defend  points  order  in  terms; 

;  of  their  need  for  defense 

(defun  reorder. by. strength  'bname  defend. points  side; 

(prog  (tmpl  tmp2  tmp3  values) 

(setq  tmpl  defend. point s  values  ''10  20  30  10  50  GO  70  SO  90  100  1000)) 
loopl 

(and  (null  (boardval  (eval  bname)  (first  tmpl))) 

(setq  tmp2  (cons  (first  tmpl)  tmp2) 
defend. points  (remove  (first  tmpl)  def end. points) )  ) 

(and  (setq  tmpl  (cdr  tmpl))  (go  loopl)) 
loop2 

(setq  tmpl  def end. points ) 

1  oop3 
(and  tmpl 

(setq  tmp3  (boardval  (eval  bname)  (first  tmpl))) 

(equai  (unit. status  bname  tmp3  'side) 
side) 

(<  (A  ( unit. status  bname  tmp3  ' prof i c xencv > 

(unit. status  bname  tmp3  ' def end. strength > > 

(first  values )  ) 

(setq  tmp2  (cons  (first  tmpl)  tmp2) 
def end. points  (remove  (first  tmpl)  def end. points )) ) 

(and  (setq  tmpl  (cdr  tmpl))  (go  loop3)  ) 

('arid  (setq  values  (cdr  values))  (go  loop2)) 

(return  (reverse  tmp2 )  ) 

) 

) 

; which. corr idor? 

;  function  used  only  by  support. ^orr idors  goal  definition 
;  it  determines  which  corridor  a  unit  is  already  supporting 
(defun  which. corr idor7  (bname  cor&goals  unitname) 

(prog  (tmpl  tmp2  maxdist  tdist) 

(setq  tmpl  cor&goals) 
loopl 

(cond  ((member  ( unit. status  bname  unitname  'location) 

(get  'general. area  (first  (first  tmpl)))) 

(return  (first  tmpl))) 

> 

(and  (setq  tmpl  (cdr  tmpl))  (go  loopl)) 

^determine  if  already  in  general  area  of  one  of  cornoors 
(setq  tmpl  cor&goals  maxdist  20) 
loop2 

(setq  tdist  (d  tance  ( uni t. status  bname  unitname  'location) 

(get  'center. point  (first  (first  tmpl));)) 
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(and  ( tdist  maxdist) 

(setq  tmp2  (first  tmpl)  maxdist  tdist)) 

(and  (setq  tmpl  (cdr  tmpl))  (go  1oop2)) 

:if  not  in  general  area  then  unit  chould  already  be  goinn 
;to  the  closest  corridor 
;tmp2  is  the  closets  corfcgoa.i. 

(return  tmp2) 

> 

) 

jroutine  to  find  paths  in  corridor 

(defun  paths_in_corr ldor  (bname  corridor  side) 

(prog  (tmpl  tmp2  tmp3) 

(setq  tmpl  (get  'paths  corridor)) 

;paths  is  a  property  cf  a  corridor 

'setq  tmp2  < get_def end-points  bname  corridor  ( opposite_side  side))) 
: def end-points  fci  other  side  are  ordered  by  weakest  point  first 
loopl 

(and  (member  (first  tmp2>  (first  tmpl)) 

(setq  tmp3  (cons  (first  tmpl)  tmp3)>> 

(and  (setq  tmpl  (cdr  tir.pl))  <  go  loopl)) 

(setq  tmpl  (union  tmp3  (get  'paths  corridor))) 

;  loopl  reorders  list  of  paths  so  that  all  paths  going  through 
;weak.e*t  enemy  defend  point  3re  first  in  the  list 
(and  ual  side  'enemy) 

^prog  <tmp4) 
loopll 

(setq  tmp4  (cons  (reverse  (car  tmpl))  tmp4>  ) 

(and  (setq  tmpl  (cdr  tmpl))  (go  loopll)) 

( setq  tmpl  tmp4 ) )  ) 

^reverse  direction  of  all  paths  for  side  enemy 
(return  (reverse  tmpl)) 

)  ) 

; routine  to  select  a  unit  from  a  set  of  unit  to  go  down  path 
(defun  best_unit_for  (bname  path  units) 

(prog  (tmpl  tmp2> 

•(setq  tmpl  units) 
loopl 

(and  (member  (unit_status  bname  (car  tmpl)  'location)  path) 

(setq  tmp2  (cons  (car  tmpl)  tmp2)>> 

;if  on  path  then  its  automatically  a  possible  best  unit 

(and  (setq  tmpl  (cdr  tmpl))  (go  loopl)) 

fcollect  list  of  units  already  on  path 

(and  tmp2  (=  (length  tmp2>  1)  (return  (car  tmp2)>> 

(and  tmp2  (return  <closest_umt  bname  (car  (reverse  path);  tf,io2>>) 

;  if  one  or  more  u.tits  on  path  pick  unit  farthest  along 
(return  ( closest_unit  bname  (first  path)  units)) 

;if  not  units  on  oath  pick,  unit  closest  to  start  of  path 
)  ) 

jselect  the  most  forward  defending  unit 

(defun  *irst_defend_unit  (bname  corridor  def end_s ide ) 

(prog  (tmpl  tmp2  tmp3) 

(setq  tmpl  (get  ' def end_pomts  corridor)) 

(cond  ((equal  defend^side  'friend; 

(setq  tmpl  (reverse  * cadr  'first  tmpl )  > > ) ) 

((equal  defend^side  'enemy) 

(setq  tmpl  (reverse  (cadr  (second  tmpl)))))) 
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loopl 

(setq  tmp2  (car  tmpl)) 
loop2 

(and  (member  (boardval  (eval  bname)  (car  tmp2) ) 

( act i ve_uni ts  defend^side) ) 

(setq  tmp3  (cons  (boardval  (eval  bname)  (car  tmp2) )  tmp3))) 

(and  (setq  tmp2  (cdr  tmp2)>  (90  loop2>) 

;tmp3  is  now  all  units  on  forward  most  defend  point 
(and  tmp3 

(prog  (tmp4  tmp5) 

(setq  tmp4  500) 

1 oopl 1 

(and  (<  (A  <unit_status  bname  (car  tmp3)  ' def end_strength ) 

(unit. status  bname  (car  tmo3)  7 prof  iciency )  ) 
i  mp4 ) 

(setq  trop4  (A  (unit. status  bname  (car  tmo3)  *'def end. strength ) 

(unit. status  bname  (car  tmp3)  'proficiency)) 
tmp5  <  car  tmp3 ) )  ) 

(and  (setq  tmp3  (cdr  tmp3))  (go  loopll)) 

(setq  tmpS  t m p 5 ) 

; select  weakest  of  forward  most  units 
)  ) 

(and  tmp3  (return  tmp3)> 

; if  a  unit  is  found  return  it 

(and  (setq  tmpl  (cdr  tmpl))  (90  loopl)) 

;if  no  unit  found  90  down  to  next  defend  points 

)  > 

;  support. area 

;  specifies  locations  that  could  be  used  to  support  multiple  corridor 
(defun  support^area  (corsfcgoals  side) 

(prog  (tmpl  tmp2  tmp3 ) 

(setq  tmp2  corsigoals) 
loopl 

(setq  tmpl  (cons  (first  (first  tmp2)>  tmol ) > 

(and  (setq  tmp2  (cdr  tmp2))  (90  loopl)) 

;get  list  of  corridors 
(setq  tmp2  (get  7 suppor t. areas  side)) 
loop2 

(setq  tmp3  (first  (first  tmp2))) 

(and  (equal  (union  tmpl  tmp3)  tmpl) 

(return  (second  (first  tmp2)))> 

(and  (setq  tmp2  (cdr  tmp2))  (go  loop2)) 

(return  (print  'error.in.support.area; > 

) 

) 

;  need  help 

:  determines  if  a  defense  is  m  trouble  or  attack  succeeding 
(defun  need.help  (bname  cor&goal  side  trouble  ratio) 

(prog  (tmpl  tmp2  df  nd.str  r»gth  atck .strngth  ) 

;if  the  other  side  is  not  attacking  then  no  support  is  needed 
(and  (equal  (second  corXgoal)  '3ttack) 

(setq  side  ( ooposi te.side  side))) 

; checking  an  attack  is  same  as  checking  defense  for  other  side 
;that  is  1*  attacking  is  succeeding  send  units  to  exploit  it 
(setq  tmpl  (length  ( get.def end_pomts  bname  (e-r  corigoal;  side))'* 
(setq  trouble. ratio  <-  trouble, r at io  (A  .3  ( sub  1  tmpl)))) 
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{decrease  trouble_ratio  threshold  for  corridors  wider  than  one  unit 
(setq  tmpl  (units_in_area  bname  (get  'general^area  (first  corXgoal))  side) 
tmp2  <units_m,area  bname  (get  'gener al^area  (first  cor&goal)) 
<oppo'>ite_side  side)  ) 

of nd,strngth  0  atck,strngth  0) 

{tmpl  and  tmp2  are  defend  and  attacking  units  in  general  area  of  corridor 
loopl 

(and  tmpl  (setq  df nd_str ngth 

( +  (A  (unit_status  bname  (car  tmpl)  7 def end, strength ) 

(unit, status  bname  (car  tmpl)  7 prof iciency )  ) 
df nd^strngth) ) ) 

(and  (setq  tmpl  (cdr  tmpl))  (go  loopl)) 

; df nd,strngth  is  total  strength  of  defending  units 
loop2 

(and  tmp2  (setq  atck_strnQth 

<+  (A  (unit, status  bname  <car  tmp2)  ' attack , strength > 

< uni t_status  bname  (car  tmp2)  'proficiency; > 
atck,strngth) ) ) 

(and  (setq  tmp2  (cdr  tmp2))  (go  loop2)  > 

; atck_strngth  is  total  stength  of  attacking  units 
(cond  <(<  df nd_strngth  .5)  (return  t) > 

((<  (quotient  atck_str ngth  df nd,strnqth )  trouble_r at io) 

(return  nil  ) ) 

((and  (equal  (second  corSgoal)  'defend) 

(null  (are, attacking  bname  (first  eorigoai)  ( opposite, side  side;)) 

( <=  (quotient  atck_strngth  df nd,strngth )  5)) 

(return  nil)) 

;if  not  yet  attacked  then  return  nil  unless  about  to  be  overwhelmed 
( t  (return  t )  )  ) 

{if  attack  to  defend  ratio  is  not  greater  than  acceptable  trouble, r ati o 
{then  no  support  should  be  provided 

> 

) 

;  uruts,in,area 

{  returns  list  of  all  units  in  are3  of  specified  side 
< def un  units, in, area  (bname  area  side) 

(prog  (tmpl  tmp2> 

(setq  tmpl  ( act i ve,um ts  side)) 
loopl 

(and  (member  (unit, status  bname  (car  tmpl)  'location) 
area) 

(setq  tmp2  (cons  (car  tmpl)  tmp2)>> 

(and  (setq  tmpl  (cdr  tmpl))  (go  loopl)) 

(return  tmp2) 

) 

) 

;  are, attacking 

{  determines  if  enemy  units  ir»  corridor  are  attacking 
(defun  are.attackmg  (bname  corridor  side) 

( pr  og  ( tmpl  ) 

(setq  tmpl  (units. in, area  bname  (get  'gener al.area  corridor)  side)) 
loopl 

(and  (null  tmpl)  (return  nil)) 

(and  (member  'list  (car  tmpl)  'attack)  unit, act ions )  (return  t)1 
(setq  tmpl  (cdr  tmpl)) 

(go  )oopl) 
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) 

) 

; determines  if  two  units  can  fight 

(defun  can.ati ack.c  lit  (bname  attacker  defender) 

(prog  (tmpl ) 

(setq  twpl  (member  (unit. status  bname  defender  'location) 

(sone..of  .control  bname  attacker))) 

(and  tmpl  (return  t) ) 

(return  nil ) ) ) 

(defur*  active. ur>  It*  (side) 

(cond  ((equal  .'id*  'friend)  f  r  iendly. units ) 

((equal  side  'enemy,  enemy. units )) > 

(defun  closest. unit  ;bna&e  location  list. of. units > 

(prog  (tmpl  tmp2  3\St  twpdist) 

(setq  dist  8  tmpl  Its t. of .units ) 
loool 

(and  (<  (setq  tmpdist  (distance  (unit. status  bname  (car  tmpl)  'location)  location)) 
d  ist ) 

(setq  dist  tmpdist  t»o2  (car  tmpl))) 

(and  (setq  tmpl  (cdr  tmol)>  (go  loopl)) 

(return  tmp2)>) 

;  equal  .intersection 

;  retur  is  the  intersection  of  two  lists  using  equal  rather  than  eq 
( def un  *qual_intersect  (listl  list2) 

(prog  (tmpl) 

(and  (or  (null  listl)  (null  list2)>  (return  nil)) 
loopl 

(and  (member  (car  listl)  list2) 

(setq  tmpl  (cons  (car  listl)  tmpl))) 

(and  (setq  listl  <cdr  list".))  (go  loopl)) 

( return  tmpl ) ) ) 

;  UNUSED  GOALS 

;  makegoal s  that  are  not  presently  used  but  embedded  concept  may  eventually  be  used 
'  ( makegoal 
' ( prevent 

*  (type  generic) 

( countergoal  (list  parol)) 

(subgoal  nil > ) ) 

' ( makegoal 

*  (execute. order  s 
(type  generic) 

(action  (prog  (tmpl) 

(setq  tmpl  gtmpargs) 
loopl 

(send. order  (second  (car  tmpl))  (third  (car  tmpl*)) 

(and  Tsetq  tmpl  (cdr  tmpl))  (go  loopl)) 

(execute. all. orders  gtmpboard) > ) 

) 

) 
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PROGRAM  5 

CONTINGENCY  GOAL  TREE 
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( def var  cgt  nil) 

;  the  cgt  is  the  conti ngency  goal  tree  that  the  planner  works  with 
;  as  its  core  representation  of  a  plan 
(defvar  fnendcgts  ml) 

(def var  enemvcgts  nil) 

:  friendcgts  and  enemycgts  is  used  to  save  successful  sequences  for 
;  friendly  and  enemy 
;  plan 

:  core  planner  routine 

;  fgoal  is  the  top  level  friendly  ooal 
;  egoal  is  the  top  level  enemy  30a! 

;  debug  mode  -  t  will  activate  various  stopping  points 
(defun  plan  (fgoal  egoal  debug_mode) 

(prog  <rslt> 

( initi al iseboard  'hypboard  'realboard) 

{sets  hypboard  to  realboard  position 

(setq  suppor ted_corr ldors  nil  uni tractions  nil) 

{these  global  variables  -are  used  by  rule  base  —  bad  form 
(display  hypboard  t) 

{displays  the  intial  position  of  search 
(setq  cqt  (list  (list  f ooal >  (list  egoal) 

(list  1) 

(list  (list  fgoal))  (list  (list  egoal)))) 

: the  cgt  is  structured  as  a  list  with  the  following  sublists 
;  a  list  of  all  friendly  goals  most  recent  first 

;  3  list  of  all  enemy  goals  most  recent  first 

{  a  list  of  the  depth  in  the  contingency  goal  tree  of 

each  friend  and  enemy  goal 

{  a  list  of  friendly  goals  that  have  been  or  are  being  examined 

{  3  list  of  enemy  goals  that  have  been  or  are  being  examined 

;  loopl  is  for  adding  nodes  to  the  cgt 
loopl 

(cond  ( ( check_for_f ai lure  (first  cgt)  (third  cgt)  'friend) 

(setq  rslt’7 (failed  friend))) 

< (cheeky for _f ai lure  (second  cgt)  (third  cgt)  'enemy) 

(setq  rslt  '(failed  enemy))) 

(t  (setq  rslt  ( add^gpair ) ) )  ) 

{check  if  any  goal  on  any  side  has  failed 

:if  not  add  a  new  goal  pair  to  cgt  using  function  add^gpair 
{note  that  if  new  goalpair  was  added  rslt  will  equal  r«ew_node 
(cond  ((and  (equal  (car  rslt)  'neW_r»ode/ 

(ca n_act  (first  (first  cgt))) 

(can_act  (first  (second  cgt)))) 

( update_boar d  'hypboard  (first  (first  cgt>)  (first  (second  cgt))  debug^mode 
;  if  new  goal  pair  was  added  tner,  check  if  game  can  be  updated  and  if  so  cn  it 
{note  tn at  (first  (first  cgt))  is  the  most  recent  friendly  goal 
{  and  theat  (first  (second  cat))  is  the  most  recent  enemy  goal 
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(and  (equal  (car  rslt)  'new^node)  (30  loopl)) 

lit  new  30a!  pair  was  added  to  cot  then  process  that  new  coal  pair 
;  to  cet  another  new  coal  pair 

;  loop2  is  used  for  backtracking  and  f iodine  alternative  ooals 
loop2 

(and  (caar  cgt)  <play_out  ( reiove^l _9pai r  cgt)  nil  nil)) 

Jthis  returns  to  position  before  last  coal  pair 
(and  («odify_last_3oal  rslt) 

( or 

(and  (can^act  (first  (first  cqt)))  ( can.act  (first  (second  cot))) 
(update_board  'hypboard  (first  (first  cot>>  (first  (second  cot)) 
deb*J3_»ode  t>) 
t  > 

(30  loopl)) 

;»odify_last_3oal  tries  to  replace  most  recent  ooal  for  the  side  that  failed 
;if  an  alternative  ooal  is  found  then  the  board  is  updated  as  necessary  ar.o 
;  return  to  the  add  r*o»ae  ioou 

(setq  cot  ( remove.i^opair  cgt)) 

(and  (car  cot)  (90  ioop2M 

;  if  ar»  alternative  30a!  is  not  found  then  remove  last  ooal  pair  from  cot 
;  and  try  to  find  alternative  for  the  new  last  ooal  on  cot 
(return  rslt) 

;  whichever  side  finally  failed  to  correct  the  last  failure  has 
;  by  definition  failed 

;  rslt  will  either  be  (failed  friend)  or  (failed  enemy) 

) 

) 

;  add_opair 

;  this  routine  trys  to  add  a  new  ooal  pair  to  the  present  cot 
(defun  add^opair  <) 

Cproo  (fooals  eoo*  s  levels  freis  ereis  newfooal  neweooal  level  acted_flao» 
(setq  fooals  (first  cot)  eooals  (second  cot)  levels  » third  cot) 
frejs  (fourth  cot/  erejs  (fifth  cot)  ) 

:the  cot  is  decomposed  mto  its  component  parts 

; loopl  moves  up  the  last  branch  of  the  cot  to  find  a  90a  1  pair  that 
„  ;will  3enerate  a  pair  of  subooals 
loopl 

;the  cond  below  tries  to  oet  a  new  friendly  30a!  and  a  new  enemy  ooal 
(cond  ((and  (null  acted^flao*  (can^act  (car  fooals/)  (car._act  ‘car  e3oais>>> 

(setq  newfooal  nil  newe3oal  nil  acted_flao  t>> 

;ooal  pairs  that  resulted  in  a  board  update  may  not  have  subooals 
;acted_flao  simply  flaos  if  this  cot  has  a  board  update  ir.  it 
((and  acted. fla3  (or  * can_act  (car  fooals))  (can  act  (car  e3oals>))> 

(setq  newfooal  nil  neweooal  nil)) 

;or*ce  33  a  in  ooal  pairs  that  resulted  m  a  board  update  may  not  have  subooal 
(  <  or 

( check  _dcr*t_coritir.ue  fooals  levels  -friend# 

<  check  ^dont^con*  mue  eooals  ievels  'enemy)) 

7setq  newfooal  nil  neweooal  nil)) 

;if  either  the  friendly  or  the  enemy  ooal  ;s  r,o  1  onoer  active 
;  then  it  “he  ooal  pair  may  not  generate  a  sub  ooal 

(t  (setq  newfooal  *  oet  _  sub  'hyoboard  (car  foGals)  mi  frier,  d> 
neweooal  (oet^sub  'hypboard  (car  eooals/  nil  'ene/-y>/> 

;otherwise  try  to  oet  new  ooals  for  betn  sides 


A-33 


) 

;the  cond  below  processes  the  results  of  the  above  cor»«j 
(cor.d 

((and  newfgoal  newegoal) 

(setq  cgt  (list  (cons  newfgoal  (first  cgt>> 

(cons  newegoal  (second  cgt)) 

(cons  (addl  (car  levels))  (third  cgt)) 

(cons  (list  newfgoal)  (fourth  cgt)) 

(cons  (list  newegoal)  (fifth  cgt)))) 

(return  (list  'new^node  (list  newfgoal  newegoal)))) 

:if  new  goals  for  both  sides  then  add  these  to  the  cgt  and  return 

((and  (null  newlgoal)  (null  newegoal)) 

(setq  level  (car  levels)) 

< prog  ( > 
loopl 1 

*  setq  f  goals  <cdr  fgoals)  egoals  (cdr  egoals)  level*  '.cdr  levels/ 
frejs  (cdr  freis)  ereis  (cdr  ereisi) 

<ar*d  <  level  (car  levels))  (go  loopli)) 

(return  t)) 

(and  levels  (go  loopl) > 

(return  (print  *bad  goals  returned  to  too  level  sans  resolution* )>  ) 

;  if  no  new  goals  then  wove  up  one  level  or.  the  cgt  and  try  to  generate  a 
;  new  subgoal  pair  free  there 

((and  newfgoal  (null  newegoal)) 

(return  '(failed  enewyi)) 

((and  (null  newfgoal)  newegoal) 

(return  '(failed  friend))) 

:if  only  one  side  can  continue  but  not  the  ether  then  the  side  that 
leant  continue  must  have  failed 


:  modify  last  goal 

for  the  side  that  failed  this  routine  will  try  to  replace 
:  the  last  goal  in  the  cgt 
(defun  siodif y_last_goal  <because_of> 

(prog  (fgoals  egoals  levels  fre%is  ereis  r.ewgoal  level  cot  copy ) 
(setq  cgt^copy  cgt  level  (car  (third  cgt_copy>>> 

;»ake  a  copy  of  the  cgt  and  set  level  to  depth  of  last 
;goal  pair  ir»  the  cgt 
loopl 

;the  first  part  of  this  loop  (next  four  lines)  finds  th*> 

;narer*t  goal  pair  of  the  goal  pair  that  is  to  be  replaced 
(setq  cgt_copy  < remove^ l _gpair  cgt^copy) > 

;a»ove  back  to  the  previous  goal 

(and  ‘.null  (third  cgt_copy>)  (return  nil)) 

;if  cgt  is  empty  then  return  nil 
(and  level  (car  <third  cgt_copy>>> 

(go  loopl ) ) 

:if  after  moving  back  level  did  not  increase  then 
;the  parent  of  the  goal  pair  has  not  yet  beer,  found 
:at  this  point  the  parent  goal  pair  is  the  last  node 
: ir»  cgt^copy 

(seta  fgoals  (first  cgt)  egoals  (second  cgt)  levels  *  third  cgt  > 


A-34 


frejs  (fourth  cgt)  erejs  (fifth  cgt)) 

Jbreak  up  present  cgt  into  its  component  parts 

;the  cond  below  tries  to  find  an  alternative  goal  for  the 

;goal  that  failed 

(cond 

((equal  because_of  '(failed  friend)) 

< setq  newgoal 

(get^sub  'hypboard  (car  (first  cgt_copy>> 

(car  frejs)  'friend)) 

(and  (null  newgoal)  (return  r*il)> 

(setq  f goals  (cons  newgoal  (cdr  fgoals))) 

(setq  frejs  (cons  (cons  newgoal  (first  frets))  (cdr  frets J);> 

;if  friend  failed  then  try  replacing  the  friend  goal 
((equal  because^of  '(failed  eneav)) 
csetq  newgoal 

«get_sub  'hypboard  (car  (second  cgt^copy) > 

(car  erejs)  'eneay)) 

( and  (null  newgoal)  (return  nil>> 

(setq  egoals  (cons  newgoal  ccdr  egoalsi)) 

*#setq  erejs  (cons  (cons  newgoal  (first  erejs)) 

(cdr  erejs)))) 

;if  eneay  failed  then  try  replacing  the  eneay  goal 
> 

(setq  cgt  (list  fgoals  egoals  levels  frejs  erejs)  ) 

Reconstruct  the  cgt 

(return  (list  'newgoal  (second  because^of)  newgcal)) 

Return  the  result  of  aodify_l ast_goal  processing 
> 

> 

:  get  .sub 

:  this  routine  actually  controls  the  execution  of  subgoal  croces s in^ 

:  bnaae  is  the  boardr.aae 

:  goal  is  the  goal  for  which  a  subgoal  is  desired 
;  rejs  is  the  list  of  subgoals  that  have  already  been  tried 
;  side  indicates  that  it  is  an  eneay  or  friendly  goal 
(defun  get^sub  (bnaae  goal  reis  side) 

(prog  (tapl) 

•'setq  tapl  ( process_goai  bnaae  goal  side  'subgoal)) 

;the  above  gets  all  subgoals  of  goal 
loopl 

(setq  tapl  (reaove  (car  reis)  tap! >  ) 

(and  (seto  rejs  (cdr  reis))  (go  loopl)) 

;reaove  previously  tried  goals  fro*  the  list  of  subgcais 
(return  (car  tapl)) 

Return  the  first  subgoal  that  has  not  already  been  tried 
) 

> 

:  check  _f  or  jt  ai  lure 

:  detereines  if  the  aost  recent  goal  m  the  cgt  or  anv  of  its  carents  have  failed 
:  goals  is  the  list  of  all  friend  or  eneay  ooals  m  the  cgt 

;  levels  is  a  list  that  indicates  the  depth  in  the  tree  of  each  eieaent  of  goals 
;  side  is  fr  ienu  or  er,e*v 

<def*if.  check  _f  or  ai  lur  e  ‘goals  levels  side; 

(prog  -t  ^1  level) 
loop  I 
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(and  setq  tmpl  (process^goal  'hypboard  (car  goals)  *:de  #failed_if)) 

(return  (list  'failed  (car  goals)))) 

;check  if  first  goal  in  list  of  goals  has  failed 
(seta  level  (car  levels)) 

;if  goal  has  not  failed  then  level  is  depth  of  this  goal  ir.  cgt 
loop2 

(setq  goals  (cdr  goals)  levels  (cdr  levels)  ) 

;poo  last  goal  fro*  list  of  goals 
(and  (null  goals)  (return  nil)) 

;if  all  goals  have  been  poped  then  no  failure  was  found 
(and  (c=  level  (car  levels))  (go  loop2) > 

; if  last  goal  is  not  at  a  higher  level  in  the  cgt 
Jit  is  not  a  parent  of  the  goal  that  was  just  checked 
(go  locpl)) 

) 

;  check _dont_continue 

:  determines  if  the  most  recent  goal  in  the  cgt  or  ar.v  of  its  parents 
;  should  not  be  continued 

;  success  or  failure  cannot  oe  inferred  from  this  processing 
(defur.  check  dont^continue  i goals  levels  side) 

(prog  (tmpl  level) 
loopl 

(and  (setq  tmpl  < process_goal  'hvpboard  (car  goals)  side  'dont_cor*tinue_if  >  > 
(return  (list  ' dont^contmue  (car  goals)))) 

:check  if  first  goal  in  ;ist  of  goals  should  be  discontinued 
(setq  level  (car  levels)) 

;if  net  then  level  is  depth  of  goal  m  cgt 
l  oop2 

(setq  goals  (cdr  goals)  levels  (cdr  levels)) 

Jpop  last  goal  from  list  of  goals 
(and  'null  goals)  (return  nil)) 

;xf  all  goals  have  been  poped  then  no  goal  was  found  to  discontinue 
f.ar.d  *.  •  =  level  (car  levels)  >  (go  looo2>) 

:if  last  goal  is  not  at  a  higher  level  in  the  cgt 
; it  is  not  a  parent  of  the  goal  that  was  just  checked 
‘(go  loopl  >  ) 

) 

:  car.^act 

;  determines  if  the  goal  is  sufficiently  specific  so  as  to  be  able  to  update  the 
;  this  function  is  somewhat  domain  dependent  but  can  be  generic  iced 
(defun  can_act  (goal) 

( prog  (t*pl  tmp2) 

(setq  tmpl  goal) 
loopl 

(and  (null  (member  (car  tmpl)  ' (andsim  or  si**  send**)  *  return  nil)  > 

;if  any  of  the  componenet  goals  embedded  ir.  goal 

:is  not  ar.  andsim  orsim  or  send  then  it  is  not  executable 

(and  *  member  (car  tmpl)  #(ar,dsim  orsim>) 

<seto  tmpl  (cadr  tapl>> 

( orog  ( ) 
loopl 1 

(setq  tmp2  (cons  <car  tmol)  tmo2> > 

*  a  r.  j  (setq  t»pl  (cdr  tmpl))  t  go  loopilH* 

;the  above  and  gets  all  the  component  goals  of  andsim  or  or*;** 

;ano  puts  t^em  m  t»p2 
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(setq  tmpl  (car  tmp2)  tmp2  (cdr  tmp2)) 

Jtmp2  is  list  of  all  remaining  goals  and  tmpl  is  present  goal  to  check 
(and  tmpl  (go  loopl)> 

Jas  long  as  there  is  a  goal  to  check  keep  checking 
(return  t) 

Jif  all  discovered  componenet  goals  are  executable  then  entire  goal  is 
{executable 
> 

) 

(defun  update, board  (bname  fgoal  egoal  debugjnode  display, board ) 

( getfcsend, orders  bname  fgoal  'friend) 

{send  orders  defined  if  friendly  goal 
(getfcsend, orders  bname  egoal  'enemy) 

;ser»d  orders  defined  in  enemy  goal 
<e*xecute_orders  bname  di splay, board  debug, mode) 

; execute  orders  is  a  routine  defined  in  domain 
) 

{  get &  send, orders 

{  assuming  goal  can  be  acted  upon  will  send  all  orders  embedded  in  goal 
\defun  getSsend, order s  (bname  goal  side) 

(prog  (tmpl  tmp2) 

(setq  tmpl  (list  goal)) 

{tmpl  starts  as  list  of  goals  to  process 
loopl 

(and  (null  tmpl)  (return  t> ) 

;if  no  more  goals  then  done 
(cond  ((equal  (caar  tmpl)  'send) 

( process, goal  bname  (car  tmpl)  side  'action) 

(setq  tmpl  (cdr  tmol)) 

(go  loopl ) ) ) 

nif  goal  is  to  send  an  order  then  send  order  using  action  slot  of 
{goal  definition 

(and  (member  (caar  tmpl;  '(andsim  orsim)) 

(prog  O 

(setq  tmp2  (cadar  tmpl)  tmpl  (cdr  tmpl)> 

Loopl 1 

(setq  tmpl  (cons  (car  tmp2)  tmpl)) 

(and  (setq  tmp2  (cdr  tmp2)>  (go  loopll)) 

(return  t)  ) 

(go  loopl) 

;if  i.^st  goal  is  concatenation  of  goals  then  got 
; component  goals  put  them  m  tmpl  and  process  these  goals 
) ) 

;  remove_l_gpai r 

;  returns  all  but  the  last  goal  pair  of  a  cgt 
(defun  remove, l,gpair  (cgt,l ike  ) 

(prog  ( cgt, to, re turn ) 

(or  cgt_like  (return  nil)) 

{this  loop  gets  the  cdr  of  each  element  of  cgt, like  and  puts 

Jit  into  cgt_to, return 

loopl 

(cond  ((atom  (car  cgt, like))  (return  'error, in, r emove,l, pair ) > 

(i  (setq  cgt . to, return  (cons  (cdr  (car  cqt^.lil'e))  eg to, return ))) ) 
(and  (setq  cgt_iike  (cdr  cgt. like))  (go  loopl)) 

Ja  cgt  has  five  elements  so  above  loop  goes  five  times 
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(return  (reverse  cgt.to.r eturn ) ) 

{return  cgt  sans  last  goal  pair 

) 

) 

;  play^out 

{  steps  through  all  the  nodes  of  a  cgt  and  updates  the  board  accordingly 
(defun  play.out  <cgt_copy  debug^mode  displ ay  .boar d ) 

(prog  (fgoals  egoals) 

< setq  fgoals  (reverse  (first  cgt. copy)) 

egoals  (reverse  (second  cgt.eopy))) 

; get  friendly  and  enemy  goals  in  the  cgt 
(initial i seaboard  ' hypboard  ' real board  ) 

{reset  board  to  initial  position 

(setq  supported.cor r idors  nil  unit. actions  nil) 

{reset  global  lists 
loopl 

(and  (car  cgt_copy> 

(can.act  (first  fgoals))  (can_act  (first  egoals)) 

{check  if  goal  pair  is  executable 

(or  ( getSsend. orders  'hypboard  (first  fgoals;  'friend)  t) 

(or  (getlsend.orders  'hypboard  (first  egoals)  'enemy)  t) 

{send  orders 

(execute.orders  'hypboard  display. board  debug. mode > 

{execute  orders 

) 

(and  (setq  fgoals  (cdr  fgoals)  egoals  (cdr  egoals))  (go  loopl)) 

{pop  last  goal  and  go  back  to  loopl 
) 

) 


A-38 


PROGRAM  6 

WARGAME 
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;  this  is  the  file  that  defines  the  wargame 

this  file  plus  a  terrain  -  unit  definition  file  would  be  sufficient 
for  manually  playing  this  game 

Note  that  since  this  is  only  an  example  game  and  r.ot  a  key  element 
of  the  ARES  project  the  documentation  here  is  not  as  detailed  as 
commenting  in  the  planner  itself 
GLOBAL  VARIABLES 
(defvar  globalarq  nil) 

:  whenever  a  global  arguement  is  needed  always  use  this 
;  may  be  useful  for  instance  if  want  to  pass  a  single  parameter 
;  into  a  roapcar 
(defvar  initial  nil) 

(defvar  realboard  nil) 

(defvar  hypboard  nil) 

;  the  game  allows  use  of  any  of  three  boards  referred  to  as 
;  initial  real board  and  hypboard 

;  the  game  can  be  played  on  any  of  these  three  boards 
;  this  is  done  for  the  sake  of  the  planner  and  not  the  game 
(defvar  f r ier»dly_units  nil) 

(defvar  enemy^units  nil) 

(defvar  all.units  nil) 

Jlist  of  active  friendly  and  enemy  units 
;  must  be  explicitly  saved  for  hypothetical  search 
(defvar  or evious^get^paths  nil) 

; list  of  all  get_path  results  this  saves  much  time 
:  this  varialbe  is  used  only  by  get_path 
(defvar  ene»y_orders  nil) 

(defvar  f r iend_orders  nil) 
tglobal  list  of  active  orders 
(defvar  1 i st_of _unit_properties  nil) 

(setq  1 ist_of-unit^pr oper ties  '(side  id  type  size  attack_strength  defend  strength  \ 
movement_al lowance  location  is _ active  retreated i * <?ct i or* 
locat ion_st3tus  previous_locations )  ) 

: global  list  of  all  properties  that  may  be  attached  to  a  unit 
(defvar  suppor ted^cor r idors  nil  ) 

;  a  variable  used  only  by  goal  suppor t^ccrr idor s  to  identify  if  a  corridor  has 
;  already  been  supported  this  is  a  bad  cluoe  to  be  repaired  later 
;  newturn  sets  this  variable  to  nil 
(defvar  unit_actions  nil) 

:  a  variable  used  only  bv  goal  suppor t^cor r idor s  to  identify 
"  what  is  currently  Happening  m  a  corridor 
;  this  is  also  a  bad  cluge  to  be  repaired  later 
:  BOARD  ACCESS  ROUTINES 

;  the  following  routines  are  for  the  value  of  any  board  position 
:  or  for  defining  the  relationship  between  any  two  positions 
:  note  that  a  board  is  defined  as  a  matrix- like  list  that 
;  where  each  location  is  either  a  possible  unit  location  or  a  terrain 
;  location 
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:  see  example  of  board  ir»  file  f inalterr air..  1 
:  boar oval 

'  returns  value  of  unit  location  loc  from  board 
(defun  boardval  (board  loc) 

(pres  y  x2  y2  bd ) 

(setq  ?f  (car  loc)  y  (cadr  loc)) 

(setq  x2  1  y2  1  bd  (edr  board) ) 
loopl 

(and  (equal  v2  y)  (setq  bd  *  car  bd  »  >  (30  locp2>  ) 

(setq  y2  (addl  y2)  bd  (eddr  bd)) 

(30  loopl) 

loops 

(and  (equal  >:2  x)  (return  <cadi  bd))) 

(setq  ;<2  (add  1  x2>  td  (eddr  bd)) 

(ao  lcop2) 

*  > 

;  bcardset 

:  returns  a  board  that  is  same  as  input  board 
;  but  has  value  val  at  location  loc 
(defur.  boardset  (board  loc  val) 

(prog  < x  y  x2  y2  board!  board2  lstl  lst2) 

(setq  x  (car  loc)  y  (cadr  loc)  ) 

(setq  x2  1  y2  1  boardl  board  board*  nil 
lstl  ml  lst2  nil  ) 
loopl 

icond  <<>  y2  12) 

(seta  board2  (cons  (car  boardl)  board2)  ) 

(return  (reverse  hoard2>>> 

( (equal  v2  v  ) 

(setq  y2  (addl  y2)  boards 
(cons  (car  boardl)  bcardS)  boardl  fcdr  boardl) 
lstl  (car  boardl)  ooardl  (edr  boardl)) 

(go  loop2)> 

( t" 

(seta  y2  (add  y2) 

board2  (cons  (car  boardl)  board2)  boardl  (edr  board!) 
boards  (cons  (car  board)  board2;  boardl  (edr  boardl)))) 
(go  loool) 

Icons 

' cond  ((equal  x2  x ) 

(setq  x2  (aodl  x?) 

Ist2  (cons  (car  1st  1  lst2)  1st)  (edr  lstl) 
lst2  (cons  val  lsi2)  lstl  (edr  lstl))) 

*  < >  >:2  13)  (sdq  J  st2  icons  (car  1st?)  Ist2) 
boards  (cons  (reverse  lst.l'  boirdO) 

( nn  loopl ) > 

(t  (setq  x2  (addl  x2 > 

lst2  (cons  (car  lstlv  ‘ r t2 )  lstl  < cor  Isrl) 

1  st2  (cons  *#oar  liii'  1^+1  .  edr  lstl))>i 

(qo  loop2) 

)  ) 

;  cost^of _move 

;  returns  movement  cost  tor  001, in  c.»y  particular  direction 
:  bname  is  the  name  of  tn*  boar*- 

:  unit name  is  the  name  of  the  unit 

;  loc  is  the  starting  locator* 
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;  dir  is  the  direction  of  the  Move 
;  side  is  the  side  or*  the  wove 

;  terr ain_only  is  a  flag  which  if  t  will  ignore  extra  cost  for  ticvinq 

}  throuoh  other  ci<la  ^nr.o  nf  control 

(defun  cost_of_Move  (bname  umtname  loc  dir  side  terr am_only  > 

(prog  (x  y  bd  cst) 

(seta  x  (car  loc)  y  (cadr  loc) 
x  <*  x  2)  y  (A  y  2> 

x  (  +  x  (car  dir))  y  (+  y  (cadr  dir))) 

(setq  bd  (eval  bna*e)) 

:set  expanded  board  location  and  other  parameters 
( cond 

((equal  (unit^status  bnane  unitnawe  'type)  'helicopter) 

(setq  cst  1>) 

(t  (setq  cst  (anyval  bd  (list  x  v)i>)> 

<  cond 

(<-  <  +  (sbs  (car  dir))  (abs  (cadr  dir>)>  2) 

(setq  cst  (A  1.414  csi;))- 

;if  diagonal  *:ove  cost  of  wove  is  1*414  times  terrain  value 
( cond 

((and  (null  terrain_only > 

(within  _sone_of  ^control  bn  a  tie  <  opposite^?  ide  side)  loo  ) 

(return  (addl  cst))) 

(t  (return  cst) ) > 

>  > 

;  anyval 

t  uses  all  locations  unit  or  terrain  and  gets  corresponding  value 
;  this  will  be  referred  to  as  the  extended-boar d 
;  board  is  an  actual  board 
;  loc  is  the  location  on  the  board 
(defun  anyval  (board  loc) 

(prog  « x  y  x2  v2  bd) 

(setq  x  (car  loc)  y  (Cadr  loc>) 

(setq  x2  1  y2  1  bd  board) 
loop! 

(and  (equal  y2  y)  (setq  bd  (car  bd))  (go  loop2)  ) 

(setq  y2  (addl  y2)  bd  (cdr  bd)> 

( go  loopl ) 
loop2 

(and  (equal  x2  x)  (return  (car  bd))) 

(setq  x2  (addl  x2)  bd  (cdr  bd)) 

(go  loop2) 

)  > 

;  terrain^betweer* 

;  fcr  any  two  unit  locations  returns  the  terr ai revalue  between  those  two  location 
fdefun  terra in-between  (bname  from  to) 

(prog  ( di r  > 

(setq  dir  (-list  to  from/) 

(setq  from  (list  *A  (car  from/  2)  (A  (cadr  from)  2))> 

(return  t anyv?  1  (eval  bname)  <+list  from  dir))) 

) 

> 

:  displav 

;  displays  the  board  in  board 

;  cirscrn.flg  will  clear  the  whole  screen  first  if  t 
(defun  display  (board  clrscrri-f  lg  / 
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(prog  <  t  m  p  f  1  g  > 

(cone*  < clrscrn.f lg  (send  Astandar d-output A  :clear-*cre©n>  ) 

(t  (cursorpos  0  0)  (terprl)  (cursorcos  0  0))) 

(arid  < atom 'board )  (return  'bad. arguement. to. display)  ) 

( <r»  e  t  q  t  m  p  f  1  g  t ) 

(loop  for  j  from  1  to  25  do 
( p  r  i  n  c  1  1  ) 

(loop  for  j.  from  1  to  27  d o 
<  d i s  p 1  a y 1  board  (list  i  j  > ) 

(cond  (tmpflo  (princ  1  *>) 

(t  (princ  1  -  )>>) 

(and  (null  tmpflg)  (princ  (addl  (quotient  (subl  ] )  2)))) 
(terpri)  ( t  e  r  p  r  i  ) 

(  s  e  t  q  tmpflg  (null  t  m  p  f  1  g ) )  > 

(princ  1  1  ) 

:  :i.  o o p  f  o r  i  fro m  3.  to  1  3  d o 

( d  r i n  c  l /  (cond  <  < <  i  10)  (princ  *  • > ) 

( t,  '  or  inc  •'  '  )))  ) 

(or  c 1 r s c r n . f 1 9  (cursorpos  50)))) 

;  d i 0 p lay! 

:  displays  a  single  board  position 
<  defun  displayl  (board  place?) 

(pro  c)  ( t  m  p  3,  ) 

(setq  tmpl  .(anyval  board  place)) 


(  e  0  n  d  (  (  0  q  u’a  1 

tmpl 

5) 

(  p  r  i  ri  c 

•  A*  )  ) 

(  ( e  q  u  a  1 

t  m  p  1 

2) 

(princ 

•  x 1  )  ) 

((equal 

tmpl 

1 ) 

(  p  r  i  n  c 

8  # )  ) 

(  (null 

tmpl  ) 

(  p  r  i  n  c  •  -  - 

-•  )  ) 

(  t  ( p  r i n  c  tmpl))))) 

;;  UNIT  DEFINITION  AND  ACCESS  ROUTINES 
:  d e f i n e . units 

;  sets  up  a  new  unit  as  atom  'name'  with  large  prooerty  lit&t 
(defun  define. unit  (name  side  id  type  size  attack  strength  def end.fj tr ength 
proficiency  movement..*!  1  lowance  location  1  s ..act i vp  ) 

(putprop  'side  (list  side  side  side)  name) 

(putprop  'id  (list  id  id  id)  name) 

(putprop  'type  (list  type  type  type)  name) 

(putprop  'size  (list  size  size  size)  name) 

(putprop  ' at tack.s trength 

(list  attack.* trength  attack. strength  attack t r ength )  name  ) 

( putprop  ' defend .strength 

(list  def end. strength  def end. strength  defend  strength)  name*) 

( put  or  op  'proficiency 

(list  proficiency  proficiency  proficiency)  name) 

< putprop. / movement. al lowance 

(list  move merit. allow a nee  movement. allowance  movement. allow a nee)  name  ) 
(putprop  'location  (list  location  location  location)  name) 

(putprop  'is. active  (list  is. active  is. active  is. active)  namt?) 

(putprop  'retreat. direction 

( list  (list  location)  (list  location) 

(list  location) )  name) 

(putprop  '  location. status  (list  'no. conflict  nil  nil)  name) 

(putprop  '  previous. locations  (list  nil  nil  nil)  name) 

;  above  creates  the  required  property  list*;; 

tear  is  initial  status  cadr  is  real  status  caddr  is  status  on.  the -hypboard 
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(cond  ((equal  side  'friend) 

(setq  friendly. units  (cons  name  f r iendly.um ts  ) 
all.units  (cons  name  all.units))) 

((equal  side  'enemy) 

(setq  enemy. units  (cons  name  enemy.umts ) 
all.units  (cons  name  al 1. units ) ) ) ) 

;  above  updates  list  of  friend  and  enemy  units  in  play 
) 

;  put .unit. on. boar d 

;  after  a  unit  is  defined,  this  routine  will  put  it  on  the  specified  board 
;  bname  is  the  name  of  the  board 
;  unitname  is  the  name  of  the  unit 

;  location  is  the  location  that  it  will  start  at 

(defun  put.unit. on. board  (bname  unitname  location) 

(  prog  () 

(and  (boardval  (eval  bname)  location) 

(return  ' unites 1 ready, there > ) 

(set  bname  (boardset  (eval  bname)  location  unitname)) 

(set. status  bname  unitname  ' location, status  'no.conf 1 ict ) 

(set .status  bname  unitname 

' previous. locat ions  (list  location  location)) 

) 

) 

;  unit. status 

;  gets  the  specified  status  value  for  the  board  specified 
;  bname  is  the  name  of  the  board 
;  unitname  is  the  name  of  the  unit 

j  property  is  the  unit  property  to  retrieve 

(defur*  unit. status  (bname  unitname  property) 

(cond  ((epjal  bname  'initijl)  (car  (get  oroperty  unitname))) 

((equal  bname  'reaiboard)  (cadr  (get  property  unitname);) 

((equal  bname  'hypooard)  ( caodr  (get  property  unitname)))) 

> 

;  display. unit. status 

;  displays  status  of  all  properties  of  unit  that  may  be  of  interest  to  player 
(defun  display. unit. status  (bname  unitname) 

(print  (list  bname  'status  'of  unitname)) 

( terpri > 

( pr inc  ■  side  - > 

(princ  (unit. status  bname  unitname  'side)) 

( terpr i ) 

(pr inc  B  id  * ) 

(princ  (unit. status  bname  unitname  'id)) 

(princ  B  type  - ) 

(princ  (unit. status  bname  unitname  'tyoe)) 

(princ  ■  sice  *) 

(princ  (unit. status  bname  unit  *ame  'size'*) 

(terpri) 

(princ  •  attack .strength  ") 

(princ  ( unit. status  bname  unitname  ' attac* .strength )  * 

(princ  B  defend. strength  9 ) 

(princ  (unit. status  bname  unitname  defend  strength)* 

( terpri ) 

(princ  *  proficiency  *) 

(princ  (unit. status  bname  unitname  proficiency)) 

(princ  B  movement. ai lowance  *  > 
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(prmc  (unit. status  bname  unitname  #  movement.allowance)  > 
(terpri > 

(princ  •  location  *) 

(princ  (unit.status  bname  unitname  'location)  > 

(orinc  *  is. active  •) 

(or me  (unit. status  bname  unitname  'is.active)) 

( terpri ) 

> 

;  display. status 

;  displays  the  status  for  all  units  of  any  unit  property 
(defun  display.status  (bname  property) 

(prog  (tapl  tmp2> 

vsetq  taol  friendly. units  t«p2  enemy .uni ts ) 

< terpri > 

-pnr.c  *  enemy  friendly*  > 

:  cool 

'terpri) 

i  or  me  •  *  ) 

<cor>d  Hear  tmp2> 

(prmc  (list  (car  twp2) 

(unit. status  bname  tear  tmp2>  property)))) 

(t  (princ  *  *  > ) ) 

(princ  #  •) 

( cono  ( f car  tmpl ) 

(princ  (list  (car  tmoJ  ) 

(unit.siatus  bname  (car  tmpl)  property))))) 

<  setq  impl  (edr  tmpl)  tmo2  <cdr  tmp2) ) 

(and  (or  tmpl  tmp2)  (90  loop!)) 


:  set.stat- 

:  used  to  modify  real  gt  hypothetical  status  of  a  single  unit  prooertv 
;  bname  is  the  name  of  the  board 
:  unit name  is  the  name  of  tne  unit 

•  property  is  the  name  of  the  property  to  be  modified 

:  *  status  is  the  new  status, 

(defun  set. status  (bname  umtname  property  status) 

(cond  ((equal  bname  'realboard) 

( putprop  property 

(list  (unit. status  'initial  unitname  property) 
status 

(unit. status  'hypboard  umtname  property)) 
ur»  3  inane ) ) 

((equal  bname  'hypboard) 

(putprop  property 

(list  (unit. status  'initial  unitname  property) 

< unit. status  'realboard  unitname  property) 
status ) 

unitname ) )  ) 

) 

;  reset. status 

;  resets  unit  status  and  board  status  of  of. bname  to  to^bnawt- 
:  of. bname  is  the  name  of  the  board  to  change 

:  to. bname  is  the  name  of  the  board  that  of.bname  should  b<? 

:  equivalent  to 

(dexun  reset. status  (of. bname  to.b..ame> 
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<prog  (tmpl  tmp2> 

(setq  tmpl  1  ist.of  _ur*it_properties  tmp2  all. units) 
loopl 

(set. status  of. bname  (car  tmp2>  (car  taipl  ) 

< unit. status  to. bname  (car  tmp2)  (car  tmpl))) 

(and  (setq  tmpl  (cdr  tipi))  (30  loopl)) 

(setq  tmpl  1 ist.of.un i improper ties) 

(and  (setq  tmp2  (cdr  t«p2)>  (30  loopl)) 

;  above  loop  set  all  properties  of  a  unit  to  be  as  in  to. bname 
(set  of. bname  (eval  to.bname) ) 

(putprop  'tine  (3et  'time  to^bnaie)  of. bname) 

;  of.bname  is  now  reset 

(setq  tmp2  all.units  fr ^ endly. units  nil  enemy .units  nil) 
loop2 

(cond  ((and  (equal  (unit. status  of.bname  (car  ta*p2>  'side)  #  friend) 

(null  (dead.unit  of.bname  (car  t»o2>>>) 

(setq  fnendly.umts  (cons  (car  t*o2)  f  rxendly.units  > ;  > 

<  <  and  (equal  (unit. status  of  bfiaie  (car  tmp2)  '  side)  enemy) 

(null  (dead.unit  of. bname  (car  lmc2>>>'> 

(setq  enemy.units  icons  (car  tmo2)  enemy. units) > ) > 

(and  (setq  tmp2  (cdr  ttpZ> )  (30  lcop2) > 

;  above  loop  sets  up  list  of  f r iendly. units  and  enemy _umts  to  be 
:  at  status  of  of.bname 

;  note  that  this  routine  can  be  used  with  of .bname=tG_br»a«e 
;  to  set  friendly  and  enemy  units  list  properly 
(return  (list  'status  of.bname  'reset  'to  to.bname) > )  ) 

;  clear. orders 

;  this  routine  clears  the  orders  for  all  units 
;  that  is  sets  present  order  to  (r,o  order) 

(defun  clear. orders  () 

(croo  (tmpl) 

(seto  tmol  (union  friendly. units  enemy.units )  > 

(and  (null  tmpl)  (return  (print  ' er ror.in.elear .order  a > > > 
loopl 

(send.order  (car  tmpl)  Mr»o  order)) 

(and  (setq  tmpl  (cdr  t:.pi))  (30  loopl)) 

) 

) 

:  initialize. boar d 

;  copys  board  and  clears  orders 

(defun  initialise. board  (of.bname  to_br.ame> 

(resev. status  of.bname  to.bname) 

(clear  orders)  ) 

;  HOVEHENT  FUNCTIONS 

;  these  functions  define  procedures  for  movino  units 
;  move.l.space 

;  moves  a  unit  one  space  if  feasiV’o 
;  otherwise  returns  a  diagnostic  ?icv 
;  bname  is  the  name  of  the  boat  -1 

;  unit  name  is  the  name  of  the  unit  *.*.  move 

:  to  is  the  location  to  wove 

(defun  move. 1. space  (bname  unitnane  %  a ) 

(prod  (dir  meost  side  from  tmpl  ;nf let.f lg > 

(or  (setq  from  (*  .it. status  Dnam*  ame  'location))  (return  no . unit. there > ) 

(setq  dir  (list  -  (car  to)  (car  from  *  (-  (cadr  to)  *cadr  tror«*)>>* 

(cond  ((or  (>  <  at,  i  (car  dir>)  1)  *  -  *  abs  (cadr  dir>)  1>)  (return  not.one^iumb  > )  > 
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;  sets  up  frow  location  and  direction  of  wove,  reiects  if  illegal  ^ove 
(seta  twpl  (list  (boardval  (eval  bnawe;  to) 

(and  (equal  (♦  (abs  (car  dir>)  <abs  (cadr  dir>)>  2> 

(boardval  (eval  bnawe)  (list  (♦  (car  free;  (car  dir>) 

(cadr  frow)))) 

(and  (equal  <+  (abs  (car  dir))  (abs  (cadr  dir>>>  2) 

(boardval  (eval  bnawe)  (list  (car  free) 

(  +  (cadr  fro*)  (cadr  dir))))) 

) ) 

loopl 

(and  (car  twpl)  (cond  ((null  (equal 

(unit, status  bnawe  (car  twpl)  'side) 

(unit, status  bnawe  unitnawe  'side>>> 
c return  ' enewv_ur»it_ in ^the_ way >  > 

't  (and  (null  cnflct,flg)  (seta  cr«flct,flg  t  *  > )  >  > 
and  t seta  twol  (edr  twpl))  (90  ioopi>> 

:  if  enety  unit  in  way  then  wove  is  rejected  if  fne^oly  :>n;t  t her  .-.-.f let  :lo  set 
(setq  side  (unit, status  tnawe  unitnawe  'side)) 

(setq  wcost  (cost,of ,wove  bnawe  unitnawe  free  dir  side  nil)) 

( cond  (<>  wcost  (unit, status  bnawe  unitnawe  'wovewent, allowance*  5 
(return  'to_costly> ) 

(t 

(cond  <  (within, sone, of  ..control  bnawe  < oppos ite_side  side*  frow) 

(set, status  bnawe  unitnawe  'proficiency 
(subl  (unit, status  bnawe  unitnawe  'prof  iciency  > )  > 

)  > 

(change, location  bnawe  unitnawe  frow  to> 

(set, status  bnawe  unitnawe  ' wovewent, allowance 
(-  ( unit, status  bnawe  unitnawe  ' wovewent, al lowance »  acosi>>>) 

;  if  wov  is  too  costly  then  it  is  rejected  else  the  wove  is  wade 
(set, status  bnawe  unitnawe  ' r etreat,dir ection 

(cors  to  *  unit, status  bnawe  unitnane  ' retreat, direct ion> ) > 

:  retreat  direction  is  a  u:t  of  each  past  position 
( cond  ((null  cnflct_flg>  (return  t>> 

(t  (return  ' possible, problew ) > ) 

;  if  to  location  already  has  a  unit  of  sawe  side  then  3  possible  oroblew  is  returned 
;  but  wove  is  still  wade 
) 

) 

:  change, location 

;  this  is  the  routine  that  actually  changes  all  locaticr.  variables 
;  bnawe  is  the  nawe  of  the  board 
;  unitnawe  is  the  nawe  of  the  unit 
;  frow  is  the  starting  location 
;  to  is  the  ending  location 

:  function  will  allow  two  units  on  too  of  each  other  but  will  :ecor ■: 

;  possible  conflict 

(defun  charge, location  (bnawe  unitnawe  frow  to) 

(prog  (twpl) 

f setq  twpl  < another _at, location  bnawe  unitnawe)) 

(set, status  bnawe  unitnawe  'location  to) 

(cond  ((boardval  (eval  bnawe)  to) 

(setstatus  bnawe  unitnawe  ' location, status  ' oossible^conf 1 : ct * ) 

(t  (set, status  bnawe  unitnawe  ' location  status  no,conf Iict ; 

(set  bnawe  (boardset  (eval  bnawe)  to  unitnawe >>) > 
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'.set  bname  (Doardsti  (tvi I  bname)  from  tmpl)) 

) 

> 

;  seperaie. moves 

?  taKes  3  set  of  move  sequences  for  multiple  urati  and  seperates  t~.e*  into  a  series 
;  of  independent  and  time  sequences  single  nov§  steps 
(defun  seperate.moves  < bname  side) 

(prod  (tmpl  tap2  tmp3  t*p4  unitname  moves  units) 

(cond  <  (equal  side  'friend)  <setq  units  fr  iendly. uni ts>  > 

((equal  side  'enemy)  <setq  units  enemy. units > ) } 

loopl 

(cond  ((null  (equal  (car  ( pr esent.order  (car  units; )>  'move)?  <30  2oop2>)> 

(setq  unitname  (car  units)  moves  tcdr  (present  order  unit name))) 

(and  (car  moves ) 

(setq  tmpl  (cons  (list  ‘nove  Impact  br.a^e  unit name  *car  moves :  >  tool)'* 

(and  Ccadr  moves) 

(setq  tmp2  (cons  (list  'move. I  .space  rename  unitname  -cadr  uc-ves  *  •  tmp2  ;>> 

(and  icaddr  moves) 

(setq  tmp3  (cons  (list  'stove^I. space  t-name  uf.itnawe  *  c  *ddr  ^ovesi*  tso3)>) 

(and  (cadddr  moves) 

(setq  tmp4  (cons  (list  'move.l .space  bname  unitname  « cadddr  moves;)  tmo4)>> 

loop2 

(and  (setq  units  «cdr  units))  (90  IcopD) 

(return  (list  tmpl  tmp2  tmp3  tmp4>>5> 

; execute. move 

;  takes  a  set  of  Mve  sequences  for  multiple  units  and  plays  them  out  or. 

;  the  same  board 

;  bname  is  the  name  of  the  board 

:  display.board  is  a  fla?  which  if  t  will  display  board  after  mover 

(defun  execute. moves  (bname  display. board; 

e  orog  (tmpl  imp2  rsit  frnd.moves  enerny.moves  units  backup. rslt  : 

(oece  fmd. moves  cseoerate  moves  bname  friend > 
enemv.moves  * seper ate. moves  bname  'enemy.*  t 
:frnd. moves  and  enemy. moves  t%  now  a  set  of  inoe&er.oent  sinole  moves 
loop! 

(setq  tmpl  (car  frr«d. moves)  tmp2  (car  enemy .moves)  > 
loop2 

(and  tmpl  (setq  rslt  (move.  1. space  bname  ccaddr  (car  teal* 5  *.  cadddr  tear  tmpl))))) 
(setq  tmpl  (edr  tmpl)) 

(and  tmp2  (setq  rslt  tmove.l.soace  bname  (caddr  (car  tmp2)>  (cadddr  (car  tm»2l>>>) 
(setq  tmp2  (edr  tm?2>> 

(and  (or  t*pl  tmp2)  (90  loop2)  ) 

(setq  frnd. moves  (edr  frnd. moves)  enemy. moves  (edr  enemv  moves)  * 

(and  (or  frnd.moves  enemy. moves)  C90  loopl)) 

; above  loops  execute  ail  moves* 

(setq  units  (append  enemy. units  fr lendly.um ts  ) ) 
loop3 

(and  (equal  (unit. status  bname  (car  units)  *  location^ status  *  'possible  conflict) 
(setq  tnpl  < another. at. location  bname  «ear  units);) 

(setq  backup. rslt  (backup  bname  (car  units;)) 

<cor»d  ((equal  (car  bac)uo.rs!t)  still  have.conf l :c t ) 

(set  bname 

*boardset  **eval  bname) 

(unit. status  bname  <car  units;-  'location* 
t i;ar  unit  s  )  >  > 

(setq  units  <cons  (car  units)  'cons  <cadr  bacruo.rsit  >  'edr  units*;)*) 
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<t  t)> 

(set  bname  (boardset  (eval  bname) 

(unit. status  bname  tmpl  'location) 
tmpl ) ) ) 

(and  (setq  units  (cdr  units))  <30  loop3)> 

Jabove  loop  will  move. back  units  to  avoid  double  locations 
(and  display. board  (print  'all. moves. executed) ) 

(return  t) 

) ) 

;  another .at. location 

;  during  moving  of  units  more  than  one  unit  may  be  on  a  single  unit  location 
;  this  routine  determines  if  more  than  one  unit  is  at  the  location  of  unitname 
;  bname  is  the  name  of  the  board 
;  unitname  is  the  name  of  the  unit 
(defun  another. at. location  (bname  unitname) 

(prog  (tmpl  units) 

(setq  tmol  (unit. status  bname  unitname  'location) 

units  (delete  unitname  (union  friendly._ur.its  enemy. uni ts >> ) 

loopl 

(and  (null  units)  (return  nil)) 

(and  (equal  tmpl  (unit. status  bname  (car  units)  'location))  (return  (car  units))) 
(setq  units  (cdr  units)) 

(go  loopl) 

(return  nil) 

) 

) 

;  backup 

;  this  routines  backs  a  unit  up  along  the  path  it  just  took 
;  by  backing  up  the  problem  of  having  multiple  units  at  a  single  location 
;  is  resolved 

(defur*  backup  (bname  unitname) 

(prcg  (tmpl  tmp2  fig) 

(secq  tmpl  (cdr  (unit. status  bname  unitname  ' retres* .direction >) > 

<  an*.’  (null  tmpl)  (print  ' impossible. backup. problem) ) 

]oopl 

(cond  ( (null  tmpl) 

(set. status  bname  tmp2  ' locat ion. status  ' poss lble.conf 1 1 ct ) 

(set. status  bname  unitname  ' location. status  ' no.conf 1 ict ) 

(return  (list  'still_.have.conf lict  tmp2)))) 

;if  can  not  backup  further  then  return  this  fact  and  the  name  of  the  other 

; unit  that  is  at  location  this  unit  will  now  have  to  backup 

(and  (null  (setq  tmp2  (boardval  (eval  bname)  (car  tmpl))))  (setq  fig  t>) 

( cnange. location  bname  unitname  (unit. status  bname  unitname  'location)  (car  tmpl)) 
(set. status  bname  unitname  '  retreat. dir ection 

("cdr  (unit. status  bname  unitname  'retreat. direction) )  ) 

(setq  tmpl  (cdr  tmpl)) 

(and  (null  fig)  (90  loopl)) 

Jthis  loop  keeps  backing  up  one  space  at  a  time  until  unit  has 
(moved  into  an  empty  location 

(set. status  bname  unitname  ' location. status  'no. coni lict ) 

(return  (list  'no  problem. in. backup ))) ) 

;  ZONE  OF  C0NTR0l~f unctions 

;  these  routines  define  a  units  cone.of .control 
;  ad  3 acent. squares 

;  returns  all  squares  adjacent  to  a  given  location 
;  location  is  a  unit  location 
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(defun  ad jacent.squares  ( location ) 

(mapcar 

'(lambda  (k> 

(list  <  +  (car  location)  (car  k) ) 

(+  (cadr  location)  (cadr  k>))> 

'((1  0)  (-1  0)  (0  1)  (0  -1)  <1  1)  (1  (-1  1)  (-1  -1)))) 

;  cone^of _contr ol 

;  returns  none  of  contorl  of  unitname? 

;  the  sone  of  control  should  be  equal  to  all  locations  adjacent  to 
;  the  unit  that  can  be  reached  by  that  unit  m  one  jump 
;  bname  is  the  name  of  the  board 
;  unitname  is  the  name  of  the  unit 
(defun  cone^of .control  (bname  unitname) 

(setq  globalarg  (list  bname  unitname  (unit. status  bname  unitname  'location) 
<c  .’^.status  bname  unitname  ’ide))) 

■ nlarq  was  defined  usir-g  defvar 
;■  is  used  to  pass  an  argue-ment  into  the  mapcar 
; this  is  obviously  a  bad  cluqe 
(cons  (unit. status  bname  unitname  'location) 

(remove  nil 
<  mapcar 

'(lambda  <k> 

(arid  (<  ( cost.of .move  (car  globalarg)  (cadr  globalarg) 

(caddr  globalarg)  k  ( cadddr  globalarg)  t)  4.5) 

(list  (+  (car  (caddr  globalarg))  (car  k  ) ) 

<+  (cadr  (caddr  globalarg))  (cadr  k))))) 

'((1  0)  (-1  0)  (0  1)  (6  -1)  (1  1)  (1  -1)  (-1  1)  (-1  -1)))))) 

;  wi thin.cone.of .contr ol 

;  determines  if  a  location  is  within  cone  of  control  of  side:* 

;  this  is  equivalent  to  the  location  being  within  the  cone  of  control 
;  of  any  of  the  units  of  the  specified  sidu 
;  bname  is  the  name  of  the  board 
;  side  is  either  friend  or  enemy 
;  location  is  a  unit  location 

(defun  withm.cone.of .control  (bname  side  location) 

"(prog  (tmpl) 

(cond  ((equal  side  'enemy)  (setq  tmpl  enemy  ..units )  ) 

((equal  side  'friend)  (setq  tmpl  f r iendly. units > ) 

(t  (return  'error-m-withm-sone-of-control))) 

loopl 

(and  (null  tmpl)  (return  nil)) 

(cond  ((member  location  ( cone.of .control  bname  (car-  tmpl))) 

(return  t)> 

(t  (setq  tmpl  (edr  tmpl)))) 

(go  loool ) ) ) 

;  ATTACK  AN [i  DEFEND  ROUTINES 

;  these  routines  execute  an  attack  and  update  unit  status  and  board 
5  positions  appropriately 
;  execute.al 1 .attacks 

;  executes  enemy  and  friendly  attacks  enemy  first 
;  bname  is  the  name  of  the  board 

(defun  execute.al l.attacks  (bname) 

( execute. attack s  bname  'enemy) 

(execute. attacks  bname  'friend) ) 

;  execute. attack  s 

;  gets  all  of  the  attacks  for  one  side  and  executes  them 
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;  bname  is  the  name  of  the  board 
;  side  is  the  side  executing  attacks 

;  the  actual  attacks  are  defined  by  the  orders  for  the  side  side* 
(defun  execute. attacks  (bname  side) 

(prog  (tmpl  units  dfndlst) 

(cond  ((equal  side  'friend)  (setq  units  friendly. units)  ) 

( (eaual  side  'enemy)  (setq  units  enemy  units) ) 

(t  (return  '  err  or  exec  ute.at  tack  ))  ) 
loopl 

(cond  ((null 
(equal  (car  (setq  tmpl 

( present_order  (car  units)))) 

' attack ) ) 

(go  loop2) >  ) 

;  if  it  is  an  attack  cond  below  will  add  it  to  dfndlst 
(cond  ((member  (cadr  trool)  dfndlst) 

(setq  dfndlst 

( add  to.df  ndlst  (cadr  tmpl)  (car  units)  dfndlst))) 

( t 

(setq  dfndlst 
(cons  (cadr  tmpl) 

(cons  (list  (car  units))  dfndlst))))) 

1  oop2 

(and  (setq  units  (cdr  units))  (go  loopl)) 

; above  loops  set  up  list  a  list  of  alternatir  efending  unit 
; and  list  of  -attackers  pairs 

;such  as  (funitl  (eumtl  eunit2)  fumt2  (euni*  nit4)>  where  funit’l. 
; is  to  be  attacked  by  eunitl  and  eunit2  and  fur  is  to  attacked  by 
;eunit3  3nd  eunit4 
loop3 

(and  dfndlst  (attack  bname  (cadr  dfndlst)  (car  dfndlst))) 

(and  (setq  dfndlst  (cddr  ofndlst))  (go  loop3M 
; loop3  actual  executes  each  attack 
(return  t) 

> ) 

;  add. to.df ndlst 

;  local  routine  that  adjusts  list  of  attackers  in  dfndlst 
(defun  add.to. dfndlst  (defender  attacker  dfndlst) 

(prog  ( tmpl  ) 
loopl 

(cond  ((equal  defender  (car  dfndlst)) 

(setq  tmpl  (cons  defender  tmpl)) 

(setq  tmpl  (cons  (cons  attacker  (cadr  dfndlst))  tmpl))) 
it  (setq  tmpl  (cons  (car  dfndlst)  tmpl)) 

(setq  tmpl  (cons  (cadr  dfndlst)  tmpl)))) 

(and  (setq  dfndlst  (cddr  dfndlst))  (go  loopl)) 

(return  (reverse  tmpl)))) 

:  attack 

; this  is  the  main  routine  for  determmg  the  outcome  of  an  attack 
(defun  attack  (bname  attackers  defender) 

(prog  ( actual.atck.strgth  actual. dfnd.strgth  attack. rslt  tmp  I 
terrain .value  ter  ram.  mult  def end. pos .mult  > 

(setq  actual. atck.str gth  0  actual. df nd.strgth  0) 

;  thses  two  variables  are  used  to 

;determme  ratio  for  battle  outcome** 

(setq  tmpl  attackers) 
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loopl 

(or  (car*. attack?  bname  (car  trnpl)  defender) 

(print  (list  / illegal.attacker  (car  trnpl))) 

(delete  (car  trnpl)  attackers)) 

(and  (seta  trnpl  (cdr  trnpl))  (90  loopl)) 

;set  attackers  to  be  sublist  of  attackers 

;that  can  defend  unitary  defend  group 
(setq  trnpl  attackers) 
loop2 

( setc  terrain.value 

( ter r a in-between  bname 
(unit.status  bname  (car  trnpl)  'location) 

( uni t. status  bname  defender  'location))) 

(cond  ((equal  (unit.status  bname  (car  trnpl)  'type)  'helicopter) 

(setq  terrain. mu It  1.0)) 

((equal  terrain.value  1)  (setq  terrain. mult  1.0)) 

((equal  terrain.value  2)  (setq  terrain. mult  .75)) 

((equal  terrain. value  3)  (setq  terrain. mult  .65)) 

((equal  terrain. value  4)  (setq  terrain. mult  .4))) 

(setq  actual. atck.strgth 

(4  (A  (A  (unit. status  bname  (car  trnpl)  ' attack. strength > 
(unit.status  bname  (car  trnpl)  'proficiency)) 
terrain. mult ) 
actual. atck.strgth) ) 

(arid  (setq  trnpl  (cdr  trnpl))  (go  loop2)  ) 

;  set  actual. attack. strength  to  be  total  of  all  unit  attack  strength 
( setq  def end. pos. mult 
( cond 

((equal  (car  ( present. order  defender))  'move)  .5) 

( (null 
( equal 

(unit.status  bname  defender  'location) 

(cadr  (unit.status  bname 
defender 

'previous  locations) ) ) ) 

.75) 

(t  1.0) )) 

( setq  actual.dfnd.strgth 

(+  (A  (A  (unit.status  bname  defender  ' def end. strength ) 
(unit.status  bname  defender  ' pr of iciency ) ) 
def end. pos. mult ) 
actual.dfnd.strgth) ) 

;total  defend  strength  now  set 
( setq  attack. rslt 

(battle. outcome  actual. atck.strgth  actual. dfnd  strgth) > 

(setq  at tack. rslt 
(list 

(quotient  (cbt  attack. rslt)  (length  attackers)) 

(cadr  attack. rslt) ) ) 

jeffect  on  each  attacking  unit  is  now  define*! 

(setq  trnpl  attackers) 
loop4 

(set. status  bname  (car  trnpl ) 

'proficiency 

<-  (unit.status  bname  (car  trnpl)  'proficiency) 

(car  attack.rslt) ) > 
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(and  (dead_umt  bname  (car  tmpl))  (remove  bname  (car  tmpl))) 

(arid  (setq  tmpl  <cdr  tmpl))  (go  loop4)  ) 

{attackers  status  now  reset 
<set_status  bname  defender 
'prof iciency 

<“  (unit_status  bname  defender  'proficiency) 

(cadr  attack_r sit ) ) ) 

(and  (deadjjnit  bname  defender) 

(r emove.f rom^game  bname  defender)) 

{defender  status  now  reset 
)  ) 

;  can_attack? 

;  determines  if  attacker  can  legally  attack  defender 
;  a  unit  can  only  attack  another  unit  that  is  within  the  attacking 
{  unit  zone  of  control 
{  bname  is  the  name  of  the  board 

:  attacker  is  the  name  of  the  potential  attacking  unit 
;  defender  is  the  name  of  the  potential  defending  unit 
(defun  can_attack?  (bname  attacker  defender) 

(prog  ( ) 

(and  (member  < unit_status  bname  defender  'location) 
issone_of ^control  bname  attack  er  > ) 

(return  t ) ) 

(return  nil))) 

;  dead _u nit 

;  determines  if  unit  is  no  longer  active 
;  when  a  units  proficiency  drops  to  0  then  it  is 
;  removed  from  the  board 
(defun  dead^umt  (bname  unitname) 

(<  (umt_status  bname  unitname  'proficiency)  .01)) 

;  r  emove_,f  rom_game 
{  removes  a  unit  from  play  of  game 

;  bname  is  the  name  ox  the  board  to  remove  unit  from 
{  unitname  is  the  name  of  the  unit  to  remove 
(defun  remo  *e_f rom^game  (bname  unitname) 

(.prog  (tmpl  5 

(setq  tmp]  (unit.,  status  bname  unitname  'side)) 

(cond  ((equal  tmpl  'frunai 
( seto  f r iendlv_unit s 
(remove  unitname  f r ier»dly_uni ts > > ) 

((equal  tmpl  'enemy) 

(setq  enemy_urnt% 

(remove  unitname  enemy_um tc > ) )  ) 

{above  cond  removes  unit  for  list  of  active  units 
<set_«tatus  bname  unitname  'is_active  nil) 

;a  property  of  a  unit  is  whether  or  not  it  is  active 
;  Inis  is  set  to  nil 
(set  bname 

(boardset  (eval  bname) 

(unit_status  bname  unitname  'location) 
nu)) 

;the  unit  is  removed  from  the  board  bname 
> 

) 

;  battle.ou*  come 

{  determines  the  results  of  an  attack  m  terms  of  proficiency  losi> 
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(defun  battle_outcome  (atck_strgth  dfnd_strgth > 
(prog  (ratio) 

(setq  ratio  (quotient  atck ^strgth  df nd_str 3th )  ) 


(cond  ( ( 

ratio 

10) 

( return 

(list 

0  10)  )  ) 

iC. 

ratio 

9) 

(return 

(list 

0 

9)  )  > 

(  (> 

ratio 

8) 

(return 

( list 

0 

8)  )  ) 

( (> 

ratio 

7) 

(return 

(list 

1 

7) )  ) 

( <> 

ratio 

6) 

(return 

( list 

1 

6) )  ) 

<<> 

ratio 

5) 

(return 

(list 

2 

5))  ) 

(  <> 

ratio 

4) 

(return 

( list 

2 

4) )  ) 

( <> 

ratio 

3) 

(return 

(list 

3 

3) )  ) 

( <> 

ratio 

2) 

(return 

(list 

4 

2) )  ) 

<<> 

ratio 

1.5 

>  (return  (list 

4  1.5)) > 

(<> 

ratio 

1) 

(return 

(list 

4 

1>>) 

( <:, 

ratio 

.5) 

(return 

(list 

5  1))) 

(  O 

ratio 

.3) 

t return 

(list 

7  1)  )  ) 

(t 

(return  (list  9  0)))))) 

;  THESE  ROUTINES  DEFINE  TOP  LEVEL  GAME  AND  ACTIVITIES  DURING  A  TURN 
*  display_order s 

:  will  display  all  orders  for  given  side 
(defun  display_or ders  (side) 

(prog  (tmpl  tmp2> 

(cond  ((equal  side  'friend)  (setq  tmpl  fnendly_units)  ) 

((equal  side  'enemy)  (setq  tmol  enemy_units) ) 

<t  (return  (print  'error_in_disDlay_orders ) ) ) ) 

(print  (list  side  'ORDERS  'ARE*)) 
loopl 

( print  (car  tmpl > ) 

(prmc  *  * ) 

(setq  tmp2  ( presenter  der  (car  tmpl))) 

(princ  tmp2) 

(and  (seto  tmpl  (cdr  tmpl))  (go  loopl)) 

-  ) 

;  send^order 

;  will  send  an  order  to  identified  unit 
;  ’  unit name  is  the  name  of  the  unit 
;  order  is  the  new  order  for  that  unit 
(defun  send_order  (unitname  order) 

(prog  (tmpl) 

( cond 

((equal  (car  (get  'si oe  unitname))  'friend) 

(setq  tmpl  ' f r iend^orders > ) 

((equal  (car  (get  'side  unitname))  'enemy) 

(setq  tmpl  ' enemy_order s ) > 

(t  (return  (print  ' err  or _in_send_order ) ) )  ) 

(set  tmpl 

(cons  (list  unitname  order) 

(delete  (list  unitname 
( pr esent_or der  unitname)) 

( aval  tmpl )  ) ) ) 

(return 

( list  '  pr eser»t_order  unitname 
( present_order  unitname ) ) ) 

> 

;  present^order 
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{  returns  the  present  order  for  specified  unit 
;  unitname  is  the  name  of  the  unit 

;  friend_orders  is  global  list  of  present  orders  for  side  friend 
;  enemy  ..orders  is  global  list  of  present  orders  for  side  enemy 

( defun  present_order  (unitname) 

(prog  (tmpl) 

(and  (null  unitname) 

(return  '  no_umt_  in_present )  ) 

( cond 

'((equal  (car  (get  'side  unitname))  'friend) 

(setq  tmpl  f r i end^or ders >  ) 

((equal  (C3r  (get  'side  unitname))  'enemy) 

(setq  tmpl  eneoy_order s ) > 

(t  (return  (print  ' error  _in_pr<?sent_order  ) ) )  ) 

{tmpl  is  set  to  list  of  orders 
ioopl 

(and  (equal  (caar  tmpl)  unitname) 

(return  (cadar  tmpl))) 

(and  (setq  tmpl  (cdr  tmpl))  (go  loop!)) 
f loool  will  return  an  order  if  one  is  found 
(return  *  <no_order ) ) 

{if  no  order  found  the  return  no  order 
) 

) 

;  new_turn 

{  initialises  the  units  for  a  new  turn 
;  resets  the  movement_al lowance 
;  list  of  previous_locations 

;  the  order  to  no  order 

;  golobal  list  of  supported  .corridors  to  nil 

{  tiime  of  board  to  time  +  1 

(defun  new_turn  (bname) 

(prog  vAmpl) 

(setq  tmpl  -union  f r iendly _uni ts  enemy_umts )  ) 

Ioopl 

(s^t_status  bname  (car  tmpl)  'movement_al lowance 

( umt.status  'initial  (car  tmpl)  ' move»ent_al lowance > > 

{movement  allowance  iu  reset  to  intial  value  usually  4 
(set_status 

bname  (car  tmpl)  ' pr evious_locat ions 

(cons  ( urn t_status  bname  (car  tmpl)  'location) 

<unit_status  bname  (car  tmpl) 

' pr evious_l oca t ions) ) ) 

;a  list  cf  locations  at  previous  turns  is  saved 
(send^order  (car  tmpl)  ' ( no^order ) ) 

{unit  has  no  t"der  at  beginning  of  turn  this  default  could  be  removed 
{leaving  unit  with  standing  orders 
(and  (setq  tmpl  (cdr  tmpl))  (go  Ioopl)) 

{Ioopl  resets  status  for  each  unit 
(setq  supported_corr ldors  nil) 

{ suppor ted^corr ldors  is  global  variable  used  by  knowledge  base 

{its  existence  is  a  poor  cluge 

(putproo  'time  (addl  (get  'time  bname))  bname) 

{update  the  time 
( r*t\n  n 

(list  ' NEW  TURN 
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'TIMERS  (get  'time  bname))))) 

;  execute_order  <s 

;  executes  all  orders  for  both  side?; 

;  bname  is  the  name  of  the  board  to  execute  order  ags.n.' 

;  display_board  is  a  flag  which  if  t  will  display  th**  .  - 

< defun  execute_orders  (bname  display_bo3rd  debug^modt ‘ 

(execute_al l_at tacks  bname ) 

;  all  attack  goals  on  both  sides  are  executed  first 
(execute^moves  bname  nil) 

;  all  moves  on  both  sides  are  executed  second 
5  units  may  not  move  and  attack  on  the  same  turn 
(setq  urn  tractions  ( update_uni*_actions >  > 

;  records  what  all  the  active  units  just  did 
(and  display_board  (display  (eval  bname)  nil)) 

( and  displ ay_board 

(print  (list  '  suppor  ted^corridor  s^are  support  *l_eor  r  idor  s  ;)  '* 
(and  display_board  debug  mode 
( break ) ) 

{this  break  is  used  for  showing  the  planner  is  action  should  be 
; removed  for  actual  planning 
(new_turn  bname) 

;after  all  orders  executed  update  the  board  to  new  time 
) 

;  update Muni tractions 

;  returns  list  of  each  action  of  each  unit 

;  this  is  used  by  knowledge  base  as  a  global  variable 

;  very  much  a  cluge 

(defun  update_umt_act ions  <) 

(prog  (tmpl  tmp2) 

(setq  tmpl 

(union  fr iendly_units  enemy_units> ) 
loopl 
(setq  tmp2 

(cons  (list  (C3r  tmpl) 

(car  ( present^order  (car  tmpl))); 
tmp2)) 

(and  (setq  tmpl  (cdr  tmpl ' /  (go  loopl)) 

(return  tmp2) 

> 

) 

J  DOMAIN  SPECIFIC  UTILITIES 

;  some  utilitit  >  that  can  be  used  by  the  knowledge  base? 

;  oppoai te^side 

{returns  opposing  side  of  side  specified 
(defun  opposite_side  (side) 

(cond  ((equal  side  'friend)  'enemy) 

((equal  side  'enemy)  'friend*;  >> 

J  get^path 

{  function  to  fino  z  path  from  the  present  location  of  urntname 
;  to  th#  location  m  to 

;  bname  ii  the  name  of  the  board 

;  unitname  1*  name  of  ths  unit 

v,  to  is  the  lor^tion  to  move  to 
J  osx-  bounds  the  depth  of  the 

;  search  in  terms  of  movement  costs 

{  ~.top_3t_er***.y  is  a  flag  which  if  nil  will  not  account  for  fBct 
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;  that  the  enemy  may  be  blocking  ones  path 

(defun  get^path  (bname  unitname  to  max^cost  stop_at_enemy ) 

; if  max_cost  under  6  then  may  not  get  any  path 
(prog  (tmpl  unit_locs) 

(setq  unit^locs  ( list_umt_locs  bname  (union  fr iendly_gnits  enemy_units) ) ) 
(setq  tmpl  previous_get_paths ) 
loopl 

(and  (equal  (list  urnt^locs  unitname  to  max^cost  stop_at_enemy ) 

(car  (first  tmpl))-) 

(return  (cadr  (first  tmpl)))) 

(and  (setq  tmpl  (cdr  tmpl))  (go  loopl)) 

;if  path  has  been  previously  calculated  then  just  retrieve  it 

; if  this  starts  to  use  up  to  much  memory  then  replace  eval  bname  with  somethin 

;  more  limited  or  do  io 

(setq  tmpl  <find_path  bname  unitname 

(list  (unit^status  bname  unitname  ' location) )  to  0 
( < 1  1)  (0  1>  <1  0;  <-l  C)  (0  -1)  (1  -1)  (“1  1)  (-1  -1>> 
max^cost  stop_at_eneroy >  ) 

(setq  tmpl  (cdr  (reverse  (cadr  tmpl)))) 

;path  has  no*-  been  found  if  within  maxcost  distance 
(and  (null  tmpl) 

(setq  tmpl  (move_toward  bname  unitname  to  stop_at_enemy ) > > 

;if  no  optimal  path  found  then  simply  find  a  move_toward  path 
(and  tmpl  (setq  previous^get^paths 

(cons  (list  (list  ur»it_locs  unitname  to  max^cost  stop_at_eriemy  >  tmpl) 
previous_3et_paths) ) ) 

;  save  path  in  list  of  previous  get_paths 
(return  tmpl) 

) 

) 

:  list_unit_locs 

;  unique  board  identier  eaual  to  list  of  all  units  and  their  location 
(defun  1  ist_umt_locs  (bname  unitnames) 

( prog  ( tmpl > 

#  loopl 

(setq  tmpl  (cons  (list  (car  unitnames) 

(unit  status  bname  <c  r  unitnames)  'location)) 

tmpl)) 

(and  (setq  unitnames  (cdr  unitnames))  (go  loopl)) 

(return  (reverse  tmpl)) 

> 

) 

;  move^toward 

;  trys  to  find  a  non^optimal  path  until  within  ma,:_cost  distance 
;  this  is  used  by  get_path  if  find  path  cannot  find  a  complete 
;  path  within  maximum  allowed  movement  cost 

;  this  routine  reflects  the  inelegance  of  the  path  finding  algorithm 
:  presently  being  used 

(defun  move^towar d  (bname  unitname  to  stop_at_enemy > 

(prog  (tmpl  tmp2  tmp3  tmp4  count) 

(setq  tmpl  <unit_status  bname  unitname  'location)  count  4) 

1  oopl 

(setq  tmp2  (-list  to  tmpl;) 

(cond  ((and  (=  (car  tmpj)  0)  (cadr  tmp2)  0)> 

(setq  t»p2  ' (0  1 ) > ) 

((and  C>  (car  tmp2)  0)  ( =  (cadr  tmp2)  0)  > 
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(setq 

tmp2  ' 

(1  0) )  ) 

(  ( and 

(=  (car 

tmp2)  0) 

(< 

( C3dr 

tmp2 ) 

0)  ) 

( setq 

tmp2  ' 

(0  -1 ) ) ) 

( ( and 

(<  (car 

tmp2 )  0) 

(  = 

<  cadr 

tmp2 ) 

0)  ) 

(setq 

tmp2  ' 

(-1  0))) 

<  ( and 

(>  (car 

tmp2)  0) 

<> 

(cadr 

tmp2 ) 

0>  ) 

( setq 

tmp2  ' 

(1  1) )  ) 

( (and 

<>  (car 

tmp2)  0) 

(< 

<  cadr 

tmp2) 

0)  ) 

( setq 

tmp2 

Ml  -1))) 

( ( and 

<<  (car 

tmp2)  0) 

<> 

(cadr 

tmp2) 

0>  ) 

(setq 

tmp2 

M-l  1))) 

( (and 

<<  (car 

tmp2 )  0) 

<< 

( cadr 

tmp2 ) 

0)  ) 

( setq 

tmp2  ' 

(-1  -1))) 

) 

(and  (enemy_infcway  bname  unitname  tmpl  t»p2)  (return  tmp4)  ) 

( setq 
tmp3 
<  cdr 

(reverse  (cadr  <f±nd_path  bname 
unitname 
(list  tmpl  ) 

(+list  tmpl  tmp2> 

0 

/  ( (0  1)  (10)  (-10)  <0  -1> 

<1  1)  (1  -1)  (-1  1)  (-1  -1)) 

4  stop_at_enemy ) ) ) > ) 

(and  tmp3  (setq  tmp4  (union  tmp4  tmp3))) 

(and  <>  (setq  count  (subl  count))  0) 

(setq  tmpl  (+list  tmpl  tmp2)) 

( go  loopl )  ) 

(return  tmp4>)) 

;  find^path 

;  will  find  a  path  for  unitname  to  location  to 
;  this  is  a  recursive  search  routine  that  returns  results 
;  equivalent  to  exhaustive  search 

;  bname  is  the  name  of  the  board 
;  unitname  is  the  name  of  the  unit  to  move 

;  path_so_far  is  the  path  taken  to  this  point 

;  initially  it  is  the  list  of  the  unit  location 

;  to  is  the  location  of  the  destination 

;  cost_so_far  is  the  total  movement  cost  of  the  path_so_far 
;  dirs_to_check  is  a  list  of  allowable  directions  to  move  in 

;  max_cost  is  tha  maximum  allowable  movement  cost  of  a  path 

;  stop_at_enemy  is  flag  to  determine  is  path  search  should  account 
;  for  enemy  position 

(defun  find^path  (bname  unitname  path_so_far 
to  cost_so_far  dirs_to_check 
aax_cost  stop_at_enemy ) 

(prog  (dirs  best^so^far  next.loc  next_loc-cost  tcost  rslt) 

(cond  ((and  (cdr  path_so_f ar ) 

( enemy^m^way  bname  unitname  (cadr  path  so^far) 

(-list  (car  p3th_so_far)  (cadr  path_so_f ar ) > > > 

(return  '(100  ro_path)))> 

Jcheck  if  enemy  in  way  on  last  move 

;this  can  happen  depending  on  how  find_path  was  first  called 
(and  (equal  (car  path_so_far)  to) 
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(return  (list  cost_so_far  path_so_f ar  ) ) ) 

; if  destination  found  then  a  legal  path  has  been  found  so  it  is  returned 
(seta  tcost  (  +  max_cost  .01)  dirs  dirs^to^check ) 
loopl 

(setq  next^loc  (+list  (car  dirs)  (car  path,.  ao_f ar )  ) 

next_loc_cost  (cost _of. move  bname  unitname  (car  path_so_far)  (car  dirs) 
(unit_status  bname  unitname  'side)  nil)) 

(and  O  tcost  <+  (+  cost_so_far  next_loc_cost ) 

(distance  (+list  (car  path_so_far)  (car  dirs))  to))) 

(>  5  next_loc_cost ) 

(null  (member  next_loc  path_so_f ar )  ) 

(cond  ( stop_at_enemy 

(or  (equal  (+list  (car  path_so_far)  (car  dirs))  to) 

(null  (enemy  in_way  bname  unitname  (car  path_so_far)  (car  dirs))))) 

<t  t)) 

(setq  rslt 

(find^path  bname  unitname  (cons  next_loc  path_so_f ar )  to 
<+  next.loc^cost  cost_so_f ar ; 
dir s^to^check  max^cost  stop_at_enemy ) > ) 

;  recursively  calls  fmd_path  if  next_loc  may  lead  to  good  path 
(and  rslt  <<  (car  rslt)  tcost) 

(setq  best_so_far  rslt  tcost  (car  rslt)  rslt  nil)) 

; if  new  path  is  cheaper f  then  use  it  as  the  standard 
(and  (setq  dirs  (cdr  dirs))  (go  loopl)) 

(cond  ((null  best_so_far)  (return  '(100  no_path>>) 

Ct  (return  best_so_f ar ) )  ) 

;  returns  either  no  path  Gf  the  best  path  so  far 
') 

) 

;  best^dir 

;  sets  the  direction  to  check  in  the  correct  general  direction 
;  makes  find^oath  more  efficient 
;  from  is  the  starting  jr»  1 1  location 
;  to  is  the  ending  unit  location 
(defun  best_dir  (from  to) 

(prog  (tmpl  tmp2) 

(setq  tmpl  (-list  to  from)  t«p2  '((0  1)  (1  0)  (1  1)  <0  -1)  (-1  0)  (-1  -1)  (1  -1> 
(cond  ((and  (  =  (car  tmpl)  0)  <>  (cadr  tmol)  0)) 

(setq  tmp2  (union  M(0  1)  (1  1)  (-1  1))  tmp2))> 

((and  (>  (car  tmpl)  0)  (=  (cadr  tmpl)  0)) 

(setq  tmp2  (union  '((1  0)  (1  1)  (1  -1))  tmp2)>) 

((and  (=  (car  tmpl)  0)  (<  (cadr  tmpl)  0)) 

(setq  tmp2  (union  '<(0  -1)  (-1  -1)  (1  -1))  tmp2))> 

((and  (<  (car  tmpl)  0)  (-  (cadr  tmpl)  0)) 

(setq  tmp2  (union  '(<-1  0)  (-1  -1)  (-1  1))  tmp2))> 

((and  (>  (car  tmpl)  0)  (>  (cadr  tmpl)  0)) 

(setq  tmp2  (union  '((1  1)  (1  0)  (0  1))  tmp2))> 

((and  (>  (car  tmpl)  0)  (<  (cadr  tmpl)  0>> 

(setq  tmp2  (union  '((1  -1)  (1  0)  (0  -1))  tmp2)>) 

({and  <<  (car  tmpl)  0)  (s  (cadr  tmpl)  0)> 

(setq  tmp2  (union  '((-1  1)  (-1  0)  (0  1))  tmp2))> 

((and  (<  (car  tmpl)  0)  (<  (cadr  tmpl)  0)) 

(setq  tmp2  (union  •'((- 1  -1)  (-1  0)  (0  -1))  tmp2)>) 

) 

(return  tmp2 ) 

) 
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) 

7 (defun  dest.dir  (from  to) 

'<<1  1)  <l“0>  <0  1>  (1  -1)  <0  -1)  (‘1  1)  («1  0)  (“1  -1))) 

;  enemy.in.way 

;  this  function  will  determine  if  an  enemy  unit  blocks  movement  in  direction  dir 
;  if  a  unit  is  in  the  way  it  will  return  this  fact  otherewise  it  returns  nil 
;  bname  is  the  name  of  the  board 
;  unitname  is  the  name  of  the  unit 

;  from  should  be  the  location  moving  from 

;  dir  is  the  direction  of  the  proposed  move 
(defun  enemy.in.way  (bname  unitname  from  dir) 

(prog  (tmpl) 

(setq  tmpl 
(list 

(boardval  (eval  bname)  <+list  from  dir)) 

(arid  (equal  (+  (-abs  (car  dir))  (abs  (cacsr  dir)))  2) 

(boardval  (eval  bnaMe ) 

(list  (+  (car  from)  (car  dir)) 

(cadr  from) ) ) ) 

(and  (equal  <+  (abs  (car  dir))  (abs  (cadr  dir)))  2) 

(boardval  \eval  bname) 

(list  (car  from) 

(+  (cadr  from)  (cadr  dir))))) 

>  ) 

loopl 

(and  (car  tmpl) 

(null  (equal 

(unit. status  bnau-  \car  tmpl)  'side) 

(unit. status  bname  *«'itname  'side))) 

(return  'enemv.umt  > ,:.the_way )  ) 

(and  (seta  tmpl  (cdr  tmp; >.  (go  loopl)) 

( return  nil))) 

;  distance 

euclidian  distance  ? 

;  will  be  less  than  or  cq  *•  to  actual  travel  distance  betweer-  from  and  to 
(defun  distance  (from  to) 

(sqrt  <+  (expt  (car  (~]i*  from  to))  2) 

(expt  (cadr  (-list  from  to)>  2)))) 

;  GENERAL  UTILITIES, 

;  these  utilies  are  not  necessarily  tied  to  this  game 
;  +list 

;  for  two  lists  of  numbers  of  equal  cist? 

;  returns  list  of  the  respective  sums  of  those  numbers 
(defun  +  list  (lstl  lst2> 

(prog  (sumlst) 

(or  (equal  (length  lstl)  (length  lst2>>  ^return  ' unequal. 1 istsJ  ) 

(or  lstl  (ret  rn  'no. list)) 
loopl 

(setq  sumlst  (cons  <  +  (car  lstl)  (car  lst2>)  sumlst)) 

(and  (setq  lstl  (cdr  lstl)  lst2  (cdr  lst2)  )  ( qo  loopl)) 

(return  (reverse  sumlst) > 

) 


f 


) 

-list 
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;  for  two  lists  of  numbers  of  equal  size  returns  list  of  the 
;  respective  subtraction  of  those  numbers 
tdefun  -list  (Istl  lst2) 

(prog  (diflst) 

Cor  (equal  (length  Istl?  (length  lst2>)  (return  'uneoual  l ists)  ) 

(or  Istl  (return  'no_list)> 
loopl 

(setq  diflst  (cons  <-  (car  Istl)  (car  lst2)>  diflst) > 

(and  (setq  Istl  (cdr  Istl)  lst2  (cdr  lst2)>  (go  loop!)) 

(return  (reverse  diflst)) 

) 

> 

J  THESE  FUNCTIONS  ARE  TO  SAVE  AND  RETRIEVE  FILES  OF  GAHE  SITUATIONS 
:  save^game 

;  saves  the  present  game  in  the  file  filename 

:  realboard  is  always  the  name  of  the  present  active  board 

;  note  that  because  previous^get^paths  is  a  long  list  this  could  be  an 

;  extensive  file 

(defun  save^game  (filename) 

<with-open-f ile  (^standard-output*  filename  'out  > 

(prog  (tmpl  tmp2> 

(write  realboard ) 

(write  al l_units ) 

(write  f r iendly_units ) 

(write  enemy_units ) 

(write  1 ist_of_unit_ properties ) 

(write  previous_get_paths ) 

(setq  tr*pl  all^units  tmp2  list_of _ur»it_properties> 
loopl 

(write  (get  (car  tmp2)  (car  tmpl))) 

(and  (setq  tmp2  (cdr  tmp2)>  (go  loopl)) 

(and  (setq  tmpl  (cdr  tmol))  (setq  t«o2  list  of  unit  croperties)  (qg  loool)> 

> 

) 

) 

;  retr ieve_game 

;  retrieves  a  game  saved  by  save_game 

;  note  that  because  previous_get_paths  is  a  long  list  this  could  be  an 

;  extensive  file 

(defun  retrieve^game  (filename) 

(with-open-f ile  ( *standard-input*  filename  '  in) 

(prog  (tmpl  tmp2> 

(setq  realboard  (read)) 

(setq  all.units  (read)  ) 

(setq  f riendly^umts  (read)) 

(setq  enemy^units  (read)  ) 

(setq  list_of _unit_properties  (read) ) 

(setq  previous^get^paths  (read)) 

(setq  tmpl  all_gnits  tmp2  1  ist_of  _umt_pr  operti  es ) 
loopl 

(putorop  (car  t»o2)  (car  tmpl)  (read)) 

(and  (setq  tmp2  (cdr  tmp2>)  (go  loopl)) 

(and  (setq  tmpl  (cdr  tmpl))  (setq  tmp2  list_of  unit  properties)  <oo  loopl)) 
) 

> 

> 
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;  save.board 

;  this  function  will  save  the  display  of  a  board  in  a  file 
•  this  allows  board  to  be  printed  later 
;  bnaee  is  the  nane  of  the  board 
;  file  is  the  r.aee  of  the  file  to  save  to 
(defun  save^board  (bnaee  file) 

( with-open-f ile  < Astandard-output*  file  'out) 

(prog  (tmpflg  board) 

(and  (null  (atoe  bna»e>)  (return  'bad^argueeent^to^save^board) > 
(setq  board  (eval  bname)) 

(setq  tttpflg  t) 

(loop  for  j  froe  1  to  25  do 
< princ  •  *  ) 

(loop  for  i  froa  1  to  27  do 

(displayl  board  (list  i  j>) 

(cond  (tepflg  (princ  •  *)> 

(t  (orinc  *  •))>) 

(and  (null  tepflg)  <princ  Caddl  (quotient  (subl  i )  2).‘H 
(terpri)  (terpri) 

(setq  tupflg  (null  tapflg))) 

(princ  *  *> 

(loop  for  i  free  1  to  13  do 
(princ  x>  (cond  <(<  i  10)  (princ  *  *)> 

(t  (princ  •  *})>) 

> )  > 
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